I would like to get a structured balance sheet from a 10-Q report with XBRL. There are tons of elements and I would like to dynamically construct the hierarchy (eg. Assets contain Current and Non-current Assets, etc.).
As I understand, for such purpose there are arc elements similar to https://xbrl.sec.gov/dei/2020/dei-pre-2020-01-31.xml
Is there any similar one for financial statements?
What you are looking for is the report specific presentation linkbase (which often contains a pre in the name; this is not a global rule though, but applies to the SEC filings). The presentation linkbase is linked to the original report through imports.
Here is an example for apple's recent 10-Q. The hierarchy (balance sheet) you are looking for is in extended link with xlink:role="http://www.apple.com/role/CONDENSEDCONSOLIDATEDBALANCESHEETSUnaudited".
Related
Background
We currently use AutoDesk Forge to display 2D models of floor plans. Users have the ability to upload new floor plans (which uploads to OSS, then translates the file) to replace existing ones, that may include new objects in the room, or slightly different positioning of existing objects. Currently, we grab certain object dbId's via viewer.getSelection() to "bind" (using the term loosely here) some external data to the object and perform certain interactions within our web app. We are using .DWG files.
Issue
When uploading a new floor plan that removes an object, it shifts dbId's of other objects, and our external binding is then inaccurate.
Question
• Are there any IDs that persist between the uploads/translations?
*We do not maintain control of the .dwg files prior to their upload, so adding attributes on the drawing before it's translated likely won't be viable for our particular case - but if that's the best (or only) approach, I would like to know to propose it as a possible solution to my team.
Example
Let's say there's a simple square room with 5 chairs, and it's rendered and visible in the viewer since it's been uploaded as room1 (object key). We identify 3 chairs by their dbIds and save that, so a user can jump right to the object in question, and we put a label on it. Then someone comes along and removes one of the chairs, uploads/translates the document again with the same object key. Now, the dbIds are changed and assigned to different chairs and as a result. Question is, is there something other than dbId that persists between the different renderings? Or, is there something that I haven't considered that would be a better approach of keeping the binding accurate between uploads?
EDIT: Same scenario happens with element ID's. An interesting finding is the element ID and dbId are tightly coupled (meaning if Object A's dbId is 3 and element ID is 6E, then a deletion happens, a new object will have 3 and 6E respectively). Also, I believe the designers creating the AutoCAD files are making these as polylines, if that makes a difference
Contingency Plan
If there's not an ID of some sort that persists, I'm considering storing the coordinates of the object we want to bind to, and later find the closest object to those x/y/z coords. Is that a possibility, to find an object close to or overlapping xyz?
Use external id.
Useful blog: https://forge.autodesk.com/blog/get-dbid-externalid
It appears that EBIT information is not very uniform across different XBRL documents.
Cross comparing data with other sources, such as Yahoo, I have seen some XBRL use the fact us-gaap:OperatingIncomeLoss to store it if using US-GAAP, or ifrs-full:ProfitLossBeforeTax if using IFRS.
However, sometimes it looks like they also use us-gaap:IncomeLossFromContinuingOperationsBeforeIncomeTaxesMinorityInterestAndIncomeLossFromEquityMethodInvestments or us-gaap:IncomeLossFromContinuingOperationsBeforeIncomeTaxesExtraordinaryItemsNoncontrollingInterest.
And sometimes many of those are actually filled with different values, so there is no way to know which one is correct.
Is there a more reliable way to retrieve EBIT data?
The use of different concepts to mean the same thing is a general problem, which is beyond the XBRL specification and usually addressed by each reporting authority.
This has been investigated notably by Charles Hoffman, CPA who suggests using his report frames. Charlie explained how to build "standardized" US GAAP balance sheets, income statements and cash flow statements with a general mapping to the original reports, in order to compare companies in the EDGAR repository.
I have a taxonomy entry point that refers to three linkbases, one of which is a presentation linkbase. When opening the entry point XSD, my XBRL tool discovers many more concepts than are present in the presentation linkbase, most of which are irrelevant for the report in question.
Is there a programmable way of deciding which concepts are to be reported, for instance by only reporting concepts which are present in a discovered presentation linkbase? Or does a human being always need to read some taxonomy-specific documentation and then select the concepts?
To give the example behind my question. I was referring to the entry point www.nltaxonomie.nl/10.0/report/bd/entrypoints/bd-rpt-ob-aangifte-2016.xsd. (The complete taxonomy is available at www.sbr-nl.nl/fileadmin/SBR/documenten/NT_2016/SBR_NT_10.0.zip.)
For instance, the XBRL editor of my choice displays concept BusinessProfitTitle coming from www.nltaxonomie.nl/10.0/report/bd/abstracts/bd-abstracts.xsd. BusinessProfitTitle is not included in the presentation linkbase www.nltaxonomie.nl/10.0/report/bd/linkroles/bd-aangifte-omzetbelasting-pre.xml, which is referred to by the entry point and which only contains concepts related to value-added tax. The entry point refers to two more definition linkbases, which seem to contain more concepts than are relevant. So I was wondering how to derive the concepts that must be reported for the entry point above, when you don’t speak Dutch and would like to derive the concepts programmatically.
There is nothing in the XBRL 2.1 specification that directly address your question.
There is something called "the formula linkbase" that might produce validation errors from content in the original instance document and the DTS. Within the "formula linkbase specification set" there are "Existence assertions" and some regulators are using the "Value assertions" for the purposes of detecting when a concept has been reported and the value reported is "valid".
This does depend somewhat on the filing system in question, but typically, the concepts covered by a presentation tree are the ones relevant to the entry point in question, and you can safely ignore all other concepts.
The schemas defining concepts are often shared by the entry points for multiple report types, so it's not uncommon to find concepts that are not covered by the presentation for a particular entry point.
I have decided to reverse engineer all my JSF (Primefaces) pages from database schema so I can have maximum Create,Read,Edit,List pages ready as per my table structure.
My questions is - What all changes (eg. datatype, size, not null etc) should be done to database tables so that I reverse engineering process handles all validations?
I know/have tried below:
1. Database - NOT NULL => Required value in JSF Page
2. Varchar(30) => Max length is 30 in JSF page
3. email column in database => Email annotation is created in POJO
What are more things which can be handled at database level so that JSF pages generated exactly(or close to exact) as required?
What can be done for password field to be generate in JSF page in reverse engineering process?
Can we add any custom JS function to page in the process to reverse engineering?
Please let me know.
Listing a exhautive list can be a intensive effort, but I do agree there are some best practice to 'smart' reverse-engineer a model into a web (jsf-primefaces) app.
You need to be able to enrich your model with the following feature to reduce extensive custom alteration.
Having written code generator starting from DB or wsdl for 20+ technologies (http://minuteproject.wikispaces.com) here are my recommandations:
Aliasing: your DB convention may not match your presentation convention (Ex: table FIN_CREDIT can appear as Credit, field EXCHANGE_RATE_ID should be better displayed as Exchange Rate ...)
Packaging: tables/views can be packaged regarding their business/technical orientations. It will allow to create menu with submenu
Content-type enrichment: indicating if a table/view holds masterdata (small amount of data), live-business-data (potentially huge number). It has an effect on how you display the cardinalities. For OneToMany with a DropDown list when is parent entity is a masterdata, otherwise an affectation subUsecase; for many2many: a picklist when the otherside is masterdata, otherwise an affectation subUseCase see (http://minuteproject.wikispaces.com/primefaces-Spring)
Stereotype: the field has a implicit validator assigned to it + a specific presentation (ex: field ending with _EMAIL have a email validator + a physical display implying email (#))
Minuteproject covers those main aspects whether by individual enrichment (of a specific table, field) or globally using conventions that span over the entire model (example: all tables ending with _TYPE are considered master-data)
A sample reverse-engineered mysql database to primefaces online on cloudbees done by minuteproject that can be found at petshopapp.minuteproject.cloudbees.net
Eventually your last concern was about adding any custom code to the reverse-engineering process:
The classical answer that you will hear is no, with the classical excuse: how can you do not know that Reverse-engineer is a process that erase your customisation!
But this statement is not true for Minuteproject. Minuteproject use updatable code, meaning that you can extend or modified portion of your code (java, xhtml, whatever the template within extension or modification areas) and at the next generation your modification will be kept! See http://minuteproject.wikispaces.com/Updatable_Generated_Code
I'm trying to build a MediaWiki-based website for a very specific purpose. Namely, I would like to create a field guide for a specific group of animals (reptiles and amphibians). Since the people I would want to generate content on the website aren't necessarily techies, I'd like to make things as easy and painless as possible for contributors.
Now, in most groups of animals, taxonomic designations are fluid, and change all the time. As an example, consider the following:
A species used to be called Genus1 species1. It was then called Genus2 species1. As of now, this species has been split into several species, say Genus2 species1, Genus2 species2, Genus2 species3, etc. In the worst case, anything about the nomenclature and classification of the species could change, including, but not limited to, the species being moved, split or merged with any other species.
For users, these changes should be transparent. That is, on typing in http://url_of_wiki/wiki/Genus1_species1, they should automatically be redirected to the lowest taxonomic group (in this case Genus2) that is non-ambiguous. Essentially, if a page is redesignated (moved, split or merged), I would like to automatically create all new pages and redirects required.
I should be able to implement this as an extension quite easily. However, I've read the MediaWiki documentation on extensions, but haven't been able to figure out just what part of MediaWiki it would be best to target.
So, the question is, is this type of extension best implemented as a parser extension, by adding new tags, or a user-interface extension, or a combination of the two (a user-interface extension backed by a parser extension)?
Nice challenging problem! If it were up to me I would solve it in a different way:
use page level for genera and
sub page level for species.
This will automatically take care of renaming since redirects will be made.
Alternatively:
- use page level for species and
- categories for genera.
Then use an if pagename template (see Wikipedia example) to change the category based on the page name.
Or possibly combine these methods.
(See also Wikis and Wikipedia)