Skip to content

Role family splits across notes() and disclosures() when a filing falls back to role names (follow-up to #1207) #1218

Description

@manantlerio

Issue Type

  • Data Quality Issue (incorrect financial values, missing data)
  • XBRL Parsing Issue (statement rendering, concept mapping)
  • Filing Access Issue (download failures, attachment problems)
  • Performance Issue (slow operations, memory problems)
  • Compatibility Issue (platform/dependency conflicts)
  • Documentation Issue (unclear instructions, missing examples)

Environment

EdgarTools Version: main (post #1214)
Python Version: 3.14
Operating System: Windows

Bug Description

Follow-up to #1207 / #1214, raised by @dgunning in review of that PR. Filed so it is
tracked rather than rediscovered later as a new bug.

What happens: in a filing whose roles fall back to role names (no human-readable
schema definition), a disclosure's parent role can be classified disclosure while its
Tables and Schedule... children stay note. Iterating either xbrl.notes() or
xbrl.disclosures() then returns a partial family.

What you would expect: a role family classifies as a unit. The Tables and Details
belonging to a disclosure follow the disclosure.

Reproduction

data/xbrl/datafiles/gahc (Global Arena Holding 10-Q), committed to the repository, so
this reproduces offline:

from pathlib import Path
from edgar.xbrl import XBRL

xbrl = XBRL.from_directory(Path("data/xbrl/datafiles/gahc"))
for s in xbrl.get_all_statements():
    if "ConvertiblePromissoryNote" in s["definition"]:
        print(f'{s["category"]:11} {s["primary_concept"]:60} {s["definition"]}')
role primary concept category
ConvertiblePromissoryNotesPayable us-gaap_DebtDisclosureAbstract disclosure
ConvertiblePromissoryNotesPayableTables us-gaap_LongtermConvertibleDebtCurrentAndNoncurrentAbstract note
ConvertiblePromissoryNotePayableScheduleOfConvertiblePromissoryNotesPayableDetails same note
ConvertiblePromissoryNotePayableScheduleOfConvertiblePromissoryNotesPayableDetailsParenthetical same note
ConvertiblePromissoryNotesPayableScheduleOfRollfowardOfConvertiblePromissoryNotesPayableDetails same note

Cause

_declares_disclosure() in edgar/xbrl/xbrl.py returns False for the children. Neither
of its two signals is present on them:

  • their role names do not lead with the Disclosure marker (ConvertiblePromissoryNotesPayableTables), and
  • their primary concept is a debt-balance abstract (us-gaap_LongtermConvertibleDebtCurrentAndNoncurrentAbstract) rather than a *DisclosureAbstract.

The parent carries us-gaap_DebtDisclosureAbstract and so moves on its own.

Scope

This does not affect the case in #1207. Oracle's roles have real schema definitions
carrying - Disclosure -, so the base role and its Tables/Details/Narrative all move
together. It bites only filings that fall back to role names, which is where gahc sits.

Before #1214 those four children were consistently, if wrongly, note; they are not newly
wrong, they are newly inconsistent with their parent.

Possible directions

Not proposing one - noting what seems available:

  1. Propagate from the parent. Group roles by a normalised name stem (strip a trailing
    Tables / Details / Policies / ScheduleOf...) and let a family member that
    declares itself a disclosure carry the rest. Closest to how a filer means it, and the
    most likely to have edge cases.
  2. Widen _declares_disclosure for children. Recognise the Tables/Details suffix
    and look up the stem's classification. A narrower version of 1.
  3. Leave classification alone and fix it at the accessor. Have notes() and
    disclosures() return whole families.

Whichever way, the guard is the same measurement #1214 used: classify every role in all 8
committed fixture filings before and after and confirm only the intended ones move.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions