Forum Replies Created

Viewing 15 posts - 256 through 270 (of 598 total)
  • Author
    Posts
  • in reply to: Tackling issues with operating lease data #184756
    David Tauriello
    Keymaster

    Hi Teji –

    In example 1, it looks like company is using the labels ‘Total lease liability’ for the tag FinanceLeaseLiability (31867) and ‘Present Value discount (5.5% weighted average)’ for OperatingLeaseLiability (-987) immediately above the total in the table.

    Search the label linkbase at https://www.sec.gov/Archives/edgar/data/355019/000035501920000007/fonr-20190930_lab.xml for text ‘Total lease liability’ and ‘Present Value discount (5.5% weighted average)’ to see these elements.

    In example 2, either the text “(in thousands)” is incorrect for the table – all of the values are in millions or the scale is incorrect on all of the values in the table (should be 3 not 6)

    Search for 29,554 in the company inline, then click the corresponding value and look at the ‘scale’ line: https://www.sec.gov/ix?doc=/Archives/edgar/data/1468666/000146866620000019/scwx10-kfy2020x01312020.htm

    I’ll circle back on example 3. FWIW, our Public Filings Database is a copy of what the SEC says it has accepted into EDGAR. The data is ‘as-filed’ – we don’t normalize what we get.

    in reply to: Tackling issues with operating lease data #184767
    Teji Abraham
    Participant

    Thanks much David. Some clarifications below.

    * Across all the data in my examples “(in thousands)” for xBRL data is from me to make the data more readable (I took the raw xbrl data and divided by 1000 to make it more presentable).

    *For Example 1, I am assuming your conclusion is that the company made an erroneous filing? Is there a possibility that the company accurately files the sec text filings but somehow ends up filing erroneous xbrl filing ?

    *For Example 2, as mentioned I made the divisions by 1000 for readability. And I did the division for all of the data items. For clarity the raw values from the xbrl api were: 29,554,000,000 (For Operating Lease Liability) and 24,669,000 (For Operating Lease Liability Non-current). And my apologies, the cik should be: 0001468666

    *Sounds good regarding Example 3.
    Thanks again, Teji

    in reply to: Getting statements and searching on network.role-description #184795
    Arthur Olevskiy
    Participant

    Thank you David. It clarifies a lot.

    By the way, using “stringmatch” can I exclude Disclosures and etc?

    And I think last question. If I want to get fact of particular statement, can I put following values for “network.role-description”: consolidate income, cash flow and balance sheet, and it will be valid?

    in reply to: The XBRL API #184906
    Arthur Olevskiy
    Participant

    Hi David,

    I have find issue with getting network.role-description.
    I use this link

    https://api.xbrl.us/api/v1/dts/{dts_id}/network?fields=network.role-description

    Following dts.id has lack of network.role-description:
    382268 – 10-Q – doesn’t have document role-description
    364559 – 10-K – doesn’t have cash flow, document and many more role-description. By the way all 10-K has this issue
    347245 – 10-Q – doesn’t have document, cash flow and many more

    Do you have other endpoint to get network.role-description for aprticular document?

    Arthur Olevskiy
    Participant

    Will this endpoint https://api.xbrl.us/api/v1/relationship/tree/search?dts.id=382268&network.link-name=calculationLink&format=flat&fields=network.role-description
    return me all network.role-description which really exist in document?

    Arthur Olevskiy
    Participant

    Where I can read about difference between calculationLink and presentationLink. They contain different network.role-description but I don’t know why and which is better for me (I’m trying to collect statements role-description from document)

    in reply to: Getting statements and searching on network.role-description #185238
    David Tauriello
    Keymaster

    Arthur – sorry for the slow response. The stringmatch parameter is simple text only – no regex or wildcards are currently possible, so excluding results can be complex, especially given that the network.role-description is a user-defined field, with each company permitted to describe statements and disclosures as they see fit.

    I hope by now you tried the query with multiple statements – IMO, you might get a closer approximation to face financials if you use (ts) with something like ‘statement balance cash income’ – ?

    David Tauriello
    Keymaster

    Arthur – use the .sort(ASC) option on your initial query https://api.xbrl.us/api/v1/dts/{dts_id}/network?fields=network.role-description.sort(ASC) – most companies put their statements ahead of disclosures, so this should make identifying these parts of the financial report a bit easier.

    The other issue you’re up against in terms of returning ‘all’ as opposed to ‘some’ is related to XBRL US Membership. Non-members can return 100 rows per query, up to 1,000 rows using the .offset(N) parameter (see this post for a brief explanation of .offset and check out the documentation for more details: https://xbrl.us/forums/topic/period-details-for-facts/#post-143964)

    Our Taxonomy Developers Handbook (TDH) has details about the different linkbases in an XBRL report: (I went to https://xbrl.us/tdh and then followed the ‘Common Linkbases’ link to this document – https://xbrlus.github.io/docs/tdh.html#a_Toc45794947)

    Arthur Olevskiy
    Participant

    Hi David, thank you for answer.

    in reply to: Tackling issues with operating lease data #185315
    David Tauriello
    Keymaster

    Teji – apologies for the delay in responding:

    • In Example 1, I don’t know that changing the label is an error, per se – it may be part of the decision-making process at the executive level or in external reporting when it composes its financial report, which serves both its existing sharehholders (who may be accustomed to certain presentation characteristics and syntaxes relative to business) and regulators. Best course would be to look at the company’s other financial reports, to see if this is consistent with past practice.
    • I’m not sure what the question is here (?) – can you post the exact reference to 29,554,000 as the company’s OLL data point in the SEC filing? The OLL value is 29,554,000,000 in the filing and it was scaled to millions by the filer <ix:nonFraction id="d22155653e1059-wk-Fact-8FBC6FAF198D16C38F98D6B453432F85" name="us-gaap:OperatingLeaseLiability" contextRef="FI2020Q4" unitRef="usd" decimals="-6" scale="6" format="ixt:numdotdecimal">29,554</ix:nonFraction> from https://www.sec.gov/Archives/edgar/data/1468666/000146866620000019/scwx10-kfy2020x01312020.htm (not thousands, as the ‘OLL Non-Current value is), so when you do your thousands recalculation for readability, it drops 000 from each number. If your question is on the NIL reported as OLL Current by the company, the Accounting Policies for the report looks like it explains the adoption of FASB ASU 2016-02, “Leases (Topic 842)” where the company elected ‘by asset class, not to record on the balance sheet a lease whose term is twelve months or less including reasonably certain renewal options’. As a result, your calculated ‘current’ value does not match what was reported (NIL)
    • In your Example #3, Similar to the first example, this is a function of the company’s use of the label linkbase. It appears you are reading its Operating Lease Liability Current from <us-gaap:OperatingLeasesFutureMinimumPaymentsDueCurrent contextRef="E14Q1" unitRef="USD" decimals="-3">769000</us-gaap:OperatingLeasesFutureMinimumPaymentsDueCurrent> and the company has labelled its OLL Current inclusive of ‘other liabilities’ `Operating lease liability classified as other liabilities, which it looks like are OperatingLeasesFutureMinimumPaymentsDueIn 2 – 5 years and labelled as ‘Present value of lease liabilities’. (see note 12 – COMMITMENTS, CONTINGENCIES AND CONCENTRATIONS OF CREDIT RISK – https://www.sec.gov/Archives/edgar/data/1108236/000101905620000200/arb_10k19.htm)
    in reply to: Tackling issues with operating lease data #185317
    Teji Abraham
    Participant

    David,
    Thanks much for the response. It seems we need to refine the xbrl api being used. Our current xbrl api for retrieving the Operating Lease data and its sub-components (using FONR with cik=0000355019 for period ending 2019-12-31) looks like:

    https://api.xbrl.us/api/v1/fact/search?entity.cik=0000355019&concept.local-name=OperatingLeaseLiability&period.instant=2020-01-01&fact.ultimus=true&fields=concept.local-name,fact.value,%20fact.ultimus,%20fact.has-dimensions,fact.id

    We are making the following assumptions when calling the above API:
    1) concept.local-name=OperatingLeaseLiability retrieves the total value of the operating lease for the specified period

    2) that as long as fact.ultimus=true is specified, the most recent value for the concept is retrieved

    3) xbrl always returns the raw data without any scaling

    We have some internal algos that cross-check on these and these seem to hold for most of the companies we are covering, except for a few outliers.

    It seems 1) and 3) may not necessarily be true and perhaps we need to constrain the api further or check the result.

    Any thoughts on how to augment the current api to also retrieve the label and scale for the concept’s fact.value ?

    Thanks again, Teji

    in reply to: Tackling issues with operating lease data #185320
    David Tauriello
    Keymaster

    Teji – thanks for the example. There may be two other forces to consider that are creating ‘outliers’ in your results.

    1. FASB’s ASU 2016-02 Leases (Topic 842)” became effective in December, 2019 – it may be an important read for your team, in understanding how companies might be revising their reporting relative to leases.
    2. inline XBRL is a growing requirement – to accommodate the presentation characteristics of it, we have additional fact fields that may be useful in evaluating data. Consider returning fact.inline-display-value and fact.inline-scale to your query. This additional information may be an effective check on the calcs you’re doing. If you look back at the OLL I posted today for Example #2, you’ll see the ‘scale’ attribute. On inline filings, I believe we parse the data into our database using this integer, multiplied by the fact inline display value, dumping the result into fact.value. I’ll reply again if that’s not correct. Eventually all companies will report inline, and will need to report a ‘scale’ attribute.
    3. On this Google Sheet, I’ve updated your query to include the two inline-related details that might be helpful (the report you shared is not inline, so these values are null and 0). The second query uses details from your query to get 1abel.text and other pieces of information, including the fact that this is a US-GAAP element (concept.namespace). The other queries would show dts.id for all US-GAAP and IFRS Taxonomies (if you wanted to investigate labels in base taxonomy versions).

    in reply to: Tackling issues with operating lease data #185326
    Teji Abraham
    Participant

    Thanks David, much appreciate the inputs and yes, Topic 842 adoption is the reason why we have been using concept.local-name=OperatingLeaseLiability and other related concepts to retrieve operating lease related data.

    The suggestions you have made make sense, essentially the process would become a two-stage process.

    Is there perhaps a single-stage approach to retrieving the operating lease components, namely: OperatingLeaseLiability, OperatingLeaseLiabilityNoncurrent, OperatingLeaseLiabilityCurrent, and OperatingLeaseRightOfUseAsset ?

    Thanks again, Teji

    in reply to: Tackling issues with operating lease data #185396
    David Tauriello
    Keymaster

    Teji –

    To get the label detail will take two stages, because you’re dealing with two distinct components of the company’s filing:

    in reply to: The XBRL API #185400
    Arthur Olevskiy
    Participant

    Hello David,

    Can you point me, how I can fetch from-3, 4, 5 from XBRL API to get insider’s transact data, please.

    Thank you.

Viewing 15 posts - 256 through 270 (of 598 total)