-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be nicer to submissions that do not follow the XBRL standard 100% #84
Comments
This would affect mainly the instance module, but there both XBRL and iXBRL parsing is affected since these are separate functions. |
Hi, Thanks for the idea, I did some code changes, added a try catch block as you suggested and used beautiful soup to fetch the wrongly filed data from the XML file directly. Here is my code:
Now, i am getting the values on terminal, sure. But the final result is in dataframe, (this is my terminal result hope you are able to see this) Thanks and regards. |
Is there a way where i can integrate this result for wrongly filed concept names and add them to the "facts" There seem to be many changes in parameters of the functions so I would rather wait for you to give an update regarding this. Thanks |
This change is now live in version 2.2.0 |
This could also apply to context id's (see #86) |
Implement some functionality that allows also for parsing XBRL reports that are violating the XBRL standart. Maybe just issue a warning and continue with parsing instead of crashing completely.
(from discussion:)
Hey,
the concepts are defined in the different taxonomy schemas imported by the instance document.
For example:
The first submission you provided failed at the concept:
"in-ca:WhetherApprovalTakenFromBoardForMaterialContractsorArrangementsorTransactionsWithRelatedParty"
which is prefixed by xmlns
"in-ca"
. This xml namespace refers to the taxonomy with namespace"http://www.icai.org/xbrl/taxonomy/2016-03-31/in-ca"
.This is linked to the schema file located at https://www.mca.gov.in/XBRL/2016/07/26/Taxonomy/CnI/IN-CA/in-ca-2016-03-31.xsd.
There you can check that the above mentioned concept is really not defined.
=> Thus the creator of this filing incorrectly used this non-existing concept which is why
py-xbrl
crashes.The problematic line is the following:
py-xbrl/xbrl/instance.py
Line 336 in 7be61f7
Here I just expect the tax.name_id_map to have the given concept (which it also should according to the XBRL standard).
There where several discussions bevore about "How to treat incorrect XBRL". Because many users of
py-xbrl
just wan't to get data out of the reports and do not care if the report could be parsed 100%.I plan to implement a functionality which would allow you to parse submissions that are incorrect (and maybe just issue a warning).
But I am not able to work on py-xbrl until Mid July (due to university stuff).
So in the mean time i would suggest to just but a "try-catch" block around the line where it's failing.
Like the following (untested):
Originally posted by @manusimidt in #83 (reply in thread)
The text was updated successfully, but these errors were encountered: