Case Study

This case study will look at using the processor to create reports drawing data from four instance documents reporting summary financials for 2014, 2015, 2016 and 2017. The instance documents are those submitted to the Danish Business Authority (Erhvervsstyrelsen) by over 50,000 Danish companies each year. Each of the four instance documents documents submitted by each company use a different version of the [DCCA taxonomy] (https://erhvervsstyrelsen.dk/sites/default/files/media/documentation_dcca_xbrltaxonomyframeworkarchitecture20151001v10_3.pdf) or the DK IFRS taxonomy.

An important requirement of this study is to make the process efficient because it is necessary to ensure that multiple taxonomy versions can be used so the integrity of the reported data can be assured for each instance document but does not degrade performance. A target for the code is to be able to produce a report for any company, one that includes data from all four instance documents, in under one second while being able to use taxonomy information to select the appropriate data. Why is this important? Some concepts, such as Equity, will be associated with multiple facts in the same year yet it is requirement of this study to include only one of the reported values associated with the Equity concept.

Source code

The source code available in the examples/case study 1 folder of the project.

The code expects the directory layout to be like this:

App

• cache
• compiled
• instances
• taxonomies
• vendor

The compile.php and report.php files include text like '// !!! change me' in locations where you might like to change constants. For example, you might prefer the cache, compiled, instances and taxonomies folders in some other locations. I have assumed the composer folder 'vendor' is a sub-folder of the app. If you have installed the processor code in some other location you will need to change the line that includes the autoload file. Again, this line is marked in both files.

About the folders

Folder	Comment
cache	during the compilation process the packages are unpacked to a folder hierarchy that mimics the implied URI starting with 'http'
compiled	the compiled taxonomies are stored in this folder. Only the .json files generated by compile.php are really needed
instances	the instance documents and the PDF files you sent are in this folder
taxonomies	the five taxonomy packages representing the annual version are in this folder
vendor	the composer folder containing XBRL processor code and projects on which it depends

It is assumed that you have followed the installation instruction on the readme page to install the processor and its dependencies.

The Taxonomies

The DCCA taxonomies are available from the erhvervsstyrelsen.dk site. This study will use the 2013, 2014, 2015 and 2016 versions of the taxonomy. At the time of writing the 2017 schema was available for review but no companies had submitted there returns using this schema.

The taxonomy packages used by this study have been included in the 'taxonomies' sub-folder so you can be sure you have the correct taxonomies if you want to run the source code of the study.

Packages

The XBRL processor supports reading taxonomies from package files that follow the XBRL Taxonomy Package specification. While the 2016 version of the DCCA taxonomy does follow the specification, the three earlier taxonomies do not.

DK DBA package

So the earlier taxonomy packages can be treated like any other package that follows the specification, a DCCA specific package class has been created. It is in the file called SimplePackage.php. The processor already includes examples for non-standard packages because earlier versions of packages available in the SEC site use two different package formats.

The need to create support for custom package formats is likely to be a common requirement especifically if the taxonomy author has been authoring packages for many years. SimplePackage.php and is a good illustration of how to create a class for a non-standard package.

DK IFRS package

The DK IFRS versions packages do not follow the XBRL Taxonomy packaging specification. Each is different in different ways. To make it possible to treat all taxonomies consistently and consistently with the DK DBA taxonomies a package class has been created.

Entry points

Modern taxonomies define one or more 'entry points'. These are XML schema documents that define collections of linkbases that together provide access to some sub-set of the functionality provided by the full taxonomy. The DCCA taxonomies are no different and each provides seven entry points one of which is an 'all' entry point that provides access to all functionality by referencing all linkbases.

Compiling

For information about compiling and why it is important see the Compiling post in this wiki.

The case study compiles the DCCA taxonomies because the objective is to report against four of them and because the complete discoverable taxonomy set (DTS) of the DCCA taxonomies includes 23 different XBRL schemas. If takes 10 seconds to create the DTS from the source XML of one DCCA taxonomy and be in a position to use it on a given machine, it takes only 200ms to load the compiled copy and be in an equivalent state of readiness. That's 50 times quicker and none of the fidelity of the original taxonomy is sacrificed.

To compile the taxonomies, create a command window and navigate to the app folder then use the command:

php -f compile.php

For me this command, which compiles the four taxonomies in the 'taxonomies' sub-folder, takes about 40 seconds to complete. When the command ends, there should be:

• four sets of files in the 'compiled' sub-folder. Only the .json files are really needed. The rest are zipped copies.
• a copy of the taxonomy package contents extracted to the 'cache' folder.

Entry point

Any one instance document will use one and only one of the available [entry points](#Entry points) supported by the taxonomy. However, because a full set of instance documents might use all of the entry points, it is necessary to support all the entry points. One way provide this support will be to compile all the entry points. However, a more pragmatic approach is to compile only the 'all' entry point then at report time use the compiled 'all' taxonomy regardless of the sub-set used by the instance document authors. Because the 'all' entry point contains the whole taxonomy, it is able to satisfy the needs of all instance documents.

As a result the names of the files in the 'compiled' folder have the format 'entryAll{$year}' where $year is the year of the taxonomy version.

Validation

Validation is enabled. This means that aspects of a taxonomy that do not meet the XBRL specification will be reported. Because the 'debugLog' option is selected, any conformance violations will be reported to the command window.

Reporting

The report aims to collect values for five concepts: Gross Profit, Profit before Tax, Net Profit, Total Equity and Total Assets. In addition, the values are need for only for the balance sheet year of each instance document and only values associated with the default member of each hypercube dimension need to be included. As a result, the facts in the instance document need to be filtered both by account, context and dimensional validity.

Running the report

A pre-requisite of reporting is that the DCCA taxonomies have been compiled. Once they have run this command in the a command window open in the app directory:

php -f report.php

Once the command is complete it will dump an array containing the reported values to the console window. The file 'output.txt' shows the output expected by running this command.

There are two things to highlight about the code in report.php:

Selecting the correct taxonomy

The code accesses the XML file of an instance document to grab the value of the tag. Using the year from the tag value the appropriate taxonomy version can be selected. The name of the appropriate taxonomy file can be passed as the second parameter to the static XBRL_Instance::FromInstanceDocument() function (the first parameter is the file name of the instance document).

Filtering facts

On line 247 the year of the balance sheet date is retrieved. There can be multiple facts for any concept so even though there will only ever be one fact associated the concept 'ReportingPeriodEndDate' its necessary to get the first value of the array returned by the getElements() function.

In line 251 the getContexts() function is used to filter the set of contexts to those which have an instance date or end date year that is the same as the balance sheet date.

On line 310, the facts for each concept are retrieved using the function ElementsByName(). This returns a specific concept and its related set of facts.

If the concept is not a primary item then the value is added to an array of result values directly. However, if the concept is a primary item then each fact is the reviewed to check it is dimensionally valid. A fact will only be dimensionally valid if the fact context includes dimensions that are consistent with the dimensions of at least one hypercube that is associated with the concept. The XBRL_Instance class includes functions to test for dimensional validity. In this case the function used is isDRSValidForFact on line 331. In order to determine the set of hypercubes associated with a primary item concept, the XBRL class includes the function getPrimaryItemDRS which is used on line 321.

The value of any dimensionally valid fact is added to the array of result values. Note that in this study, there might be more than one fact that is dimensionally valid but only one (the last found) is recorded. Facts associated with a concept that has the same context (so are period-equal, entity-equal and dimension-equal) should have the same value. If they do not it is a validation error.