Closed vladsrynty closed 4 years ago
The reason for the validation messages is the defintion linkbase 'def_NoteTaxPrepaymentsAndLiabilities_role-806000.xml'. As you can see from the validation messages, all are about et-gaap_TaxLiabilities. I have tried this with other processors and they show the same validation errors.
The specific cause is this definition arc element on line 37:
<link:definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/notAll" xlink:from="TaxLiabilities" xlink:to="AllocationByTaxLiabilitiesAndPrepaymentsHypercubeExclude" xlink:title="definition: TaxLiabilities to AllocationByTaxLiabilitiesAndPrepaymentsHypercubeExclude" order="1.0" p0:targetRole="http://xbrl.eesti.ee/role/et-gaap_2018-01-01/NoteTaxPrepaymentsAndLiabilitiesWithElementsExcluded_role-806100" p0:contextElement="scenario"/>
You can see it links TaxLiabilities to the 'AllocationByTaxLiabilitiesAndPrepaymentsHypercubeExclude' hypercube using a 'notAll' arcrole. This tells any XBRL processor that the TaxLiabilities concept should be removed from 'AllocationByTaxLiabilitiesAndPrepaymentsHypercube'.
All of the invalid contexts reference a dimension 'AllocationByTaxLiabilitiesAndPrepaymentsDimension' which is added to 'AllocationByTaxLiabilitiesAndPrepaymentsHypercube' in linkbase 'def_NoteTaxPrepaymentsAndLiabilitiesWithElementsIncluded_role-806200.xml'. Because TaxLiabilies is explicitly removed from the hypercube, and by extension the dimension, any context assigned to a TaxLiabilities fact cannot be valid.
You will be able to check this by removing line 37.
A similar potential issue exists in 'def_NoteConsolidatedTaxPrepaymentsAndLiabilities_role-806010.xml' but this time affecting facts associated with the concept 'TaxLiabilitiesConsolidated'. You don't see this issue because there are no facts reported for this concept.
You are probably right. I only have tried with Arelle viewer. It does show the results:
but it can be some sort of a workaround in Arelle. Who knows.
I try to communicate these issues to the Estonian Commercial Register.
thank you for the help!
Arelle may show the value but in my view its wrong if the purpose is to follow the taxonomy directions. In this example, the taxonomy designers have explicitly stated that TaxLiability with a dimension is invalid (it seems like a mistake to me but what do I know?). If the taxonomy directions are not going to be followed, what's the point of XBRL? If you just need to read the values then you can read the XML directly and then use the schema information to retrieve the correct labels.
If you click on the validate button in Arelle it also reports the errors. So Arelle appears to be reporting values that are not valid according to the schema.
You gents may be doing this already, but I think having another validator alongside Aurelle may be useful. I'm not sure about licensing for XWand, but I think there are a couple other choices too. Sometimes I think the validator is limited to a selection of arcroles/hypercubes/diemnsions/etc customers have asked for but not include all of XRBL specs.
Thanks for your observation though I'm not sure what you are saying. Can you expand on your comment about the limitations?
Yes, thanks for asking (and I may not be entirely correct). My experience to date has been that certain XBRL-compliant taxonomies may not be processed correctly depending on the validator. This is a reflection of a) inclusion of the latest updates to the specification and b) the expected taxonomies the validator was expected to encounter (for example: I build a tension-limited socket wrench for a spark plug in a aircraft engine; it might also fit a car but it won't set the plug properly even if its the same ANSI standard).
@vladsrynty I've updated the DFR code to improve reporting in this scenario. The DFR is designed to work best with a particular presentation hierarchy structure though I've tried to make it more generic. However, it could not cope in a scenario when some of the DFR nodes expected in the presentartion linkbase exist but not all.
In the case of [806000] Lisa: Maksude ettemaksed ja maksuvõlad the presentation nodes include information about the hypercube but not dimensions or members. As a result, the DFR code would not automatically use a relevant dimension. The update is to try to identify the missing bits and fill them in based on information from the definition linkbase. The screenshot shows the resulting report. The zip file contains the generated HTML for all roles used by test2.xbrl.
These changes have been pushed to the master branch and 'composer update' should pull them.
Note this still assumes that the error in defintion linkbase 'def_NoteTaxPrepaymentsAndLiabilities_role-806000.xml' on line 37 has been corrected. As far as the processor is concerned, line 37 is an instruction to ignore all TaxLiability facts that are associated with a dimension member (such as the 'HE*' contexts). I believe this behaviour is consistent with the lastest relevant XBRL specifications: XBRL 2.1 (2013) and XBRL Dimensions 1.0 (2012).
Wow, thank you! How did you fix the line 37?
I did report the problems to Estonian Commercial Register, but I doubt they will do something about it for current reports. Hopefully for the future ones..
I have no idea how to automate fixing errors in taxonomies though.
Another example from Estonian reporting. This report is for 2018 taxonomy.
After manually adding missing role 9300 to the extension:
I get new warnings:
test2.zip
Maybe you have some hints for this issue as well?