3. Анатомия таксономии


Эта глава с названием как у песни рок-группы 60-х годов описывает структуру таксономии XBRL. Больше внимания уделяется тому, что можно сделать с помощью таксономий, и меньше ? тому, как это делается с технической точки зрения. Мы оставим этот уровень детализации для другой главы.


Начнем вот с чего: то, что мы называем таксономией, на самом деле представляет собой, как правило, целый набор связанных документов, называемых Связанным комплексом таксономий (Discoverable Taxonomy Set), для краткости ? DTS.


Отправной точкой DTS является Схема таксономии. Это документ, на который ссылается отчет XBRL. Эта схема таксономии может ссылаться на другие документы, которые в свою очередь могут также ссылаться на другие документы и т.д.


Чтение DTS подразумевает переход по всем ссылкам до тех пор, пока не будут прочитаны все из связанных документов.


Таксономия может ссылаться на два типа документов:


  • Таксономия ? это тот случай, когда одна таксономия (Extended Taxonomy) расширяет другую таксономию (Base Taxonomy)
  • База ссылок (Linkbase) ? она используется для предоставления дополнительных сведений об определенных в таксономии концептах. Базы ссылок описывают связи между разными концептами, а также между концептом и дополнительной информацией к нему. Всего существует пять основных видов баз ссылок (каждый из которых будет подробно рассматриваться далее):
    • Определения (Definition)
    • Вычисления (Calculation)
    • Презентация (Presentation)
    • Ярлыки (Label)
    • Ресурсы (Reference)

Схематически это можно изобразить следующим образом:


image


Обратите внимание, что некоторые базы ссылок (Reference и Label) являются однонаправленными, т.е. ссылка ведет от таксономии к ресурсам базы ссылок. Другие базы ссылок (Definition, Calculation и Presentation) являются двунаправленными. Ссылки указывают от одной части таксономии к другой части.

Если необходимо, таксономия также ссылается на схему отчета XBRL «xbrl-instance-2003-12-31.xsd» (или, правильней сказать, импортирует ее) ? она содержит базовые элементы, необходимые для определения всех концептов.

Это примеры технических подробностей, которые я буду игнорировать для большей части этой книги. Я просто предполагаю, что, например, схема таксономии существует в некотором контексте (в данном случае это схема отчета XBRL), и фокусируюсь на более функциональных аспектах XBRL.

Остальная часть этой главы будет описывать каждый тип документа более подробно.


3.1. Схема таксономии


Ядро таксономии – это ее схема, которая является обязательным документом. Эта схема, о которой мы все это время говорим, на самом деле представляет собой документ XML Schema (стандарт W3C, позволяющий определять структуру XML-документов). Спецификация XBRL использует XML Schema в качестве базового языка для описания таксономий. Поверх этого базового языка она определяет набор специфичных для XBRL дополнений и ограничений.


В рамках схемы таксономии можно:


  • Импортировать другую, «базовую» таксономию, что позволяет создавать расширения существующих таксономий;
  • Определять концепты, по которым будут составляться отчеты;
  • Определять роли, используемые в базах ссылок;
  • Обращаться к базам ссылок.

3.1.1. Определение концептов


Спецификация XBRL содержит ряд требований и рекомендаций по определению концептов:


  • Каждый концепт должен иметь уникальное имя в пределах схемы таксономии;
  • Каждый концепт должен иметь атрибут Тип, который определяет, какого типа данные могут предоставляться (см. далее);
  • Концепты определяются в схеме таксономии как пункт (item) или кортеж (tuple);
    Это означает, что каждый концепт должен иметь атрибут substitution group со значением xbrli:item или xbrli:tuple
  • Рекомендуется указывать в каждом концепте атрибут с уникальным идентификатором, это упрощает обращение к концепту.

XML Schema предоставляет несколько способов улучшить определение концептов:


  • Можно указать, является ли концепт обязательным или нет;
  • Концепт может быть определен как абстрактный, тогда по нему не требуется передавать факты – это используется при расширении концептов, как описано ниже, или когда нужен корень иерархии в презентационной базе ссылок.

Кроме того, XBRL определяет для концептов атрибуты periodType и balance:


  • Атрибут periodType необходим для item-концептов (xbrli:item). Он позволяет отделить концепты, измеряемые по состоянию на определенную дату, от концептов, измеряемых за период времени;
    В отчете XBRL факты указываются в определенном контексте. Атрибут periodType концепта, по которому передается факт, должен соответствовать типу периода в контексте факта.
  • Если тип концепта – monetary, то может быть использован атрибут balance, указывающий, определяет ли концепт дебетовое либо кредитовое значение. Это очень удобно для концептов бухгалтерского учета, как напр. активы, обязательства, доходы и расходы.

Концепты могут быть расширены, образуя струкрутированное дерево концептов. Примером может служить концепт «менеджер», который расширяется на «менеджер бизнес-единицы» и «менеджер подразделения».


Поскольку в отчете XBRL могут быть указаны только факты по не абстрактным концептам, можно предотвратить передачу излишних фактов. В приведенном выше примере можно разрешать передачу фактов по концептам «менеджер бизнес-единицы» и «менеджер подразделения», но не по концепту «менеджер». Это возможно определением концепта «менеджер» как абстрактного.


3.1.1.1. Типы данных концептов

Для всех item-концептов должен быть указан тип передаваемых данных. Доступные типы данных определяются стандартом XML Schema и спецификацией XBRL.


XML Schema включает в себя следующие типы: логический (boolean), текстовый (text), десятичный (decimal), дата (date), части дат и т.д. (полный список можно найти в разделе 5.1.1.3 спецификации XBRL).


Примечание: для каждого типа из XML Schema имеется соответствующее определение типа XBRL.


Спецификация XBRL добавляет следующие типы данных:


  • Денежный (monetary) – используется для концептов, отражающих денежные значения;
  • Доли (shares) – для долевых концептов, напр. акций;
  • Простой (pure) – для концептов, в которых числитель и знаменатель выражены неявно в общем значении, напр. темпы роста, проценты;
  • Дробный (fractions) – когда факты не могут быть точно представлены никаким из других типов, напр. значение ? не имеет точного десятичного представления, но его можно указать с помощью дробного типа. Дроби задаются как отдельные значения числителя и знаменателя.

3.1.2. Ссылки на базы ссылок


Схема таксономии может содержать, и как правило содержит ссылки на Базы ссылок, предоставляющие дополнительную информацию о концептах таксономии.


Ссылка может указывать на определенный вид Базы ссылок путем определения роли. Спецификация XBRL допускает следующие роли:


  • Определение (Definition)
  • Вычисление (Calculation)
  • Презентация (Presentation)
  • Ярлык (Label)
  • Ресурс (Reference)
  • Сноска (Footnote)

Примечание: Для сносок не создается отдельных баз ссылок. Эта роль используется только в пределах отчета XBRL.


Также, возможно определить пользовательские роли, что является еще одним примером расширяемости XBRL.


Чтобы еще больше ограничить использование базы ссылок, можно определить тип фактов, на который могут указывать типы ссылок в базе.


3.1.3. Роли (roles) и роли дуг (arcroles)


Для идентификации различных типов связей внутри баз ссылок используются роли. Спецификация XBRL определяет одну базовую роль, чтобы гарантировать, что роль есть у всех ссылок. Тем не менее, автор таксономии или базы ссылок обычно определяет свои дополнительные роли. Они используются для группировки ссылок в так называемые базовые наборы (base sets). Такая сегментация может быть полезна, например, для определения различных разделов отчета при использовании презентационной базы ссылок. В базе вычислений они необходимы для всех вычислений кроме самых примитивных, чтобы предотвратить ошибки из-за смешивания связей.


Связи, которые определяются дугами, типизируются ролями дуг (arcroles). Основные дуги, такие как «concept-label» или «summation-item» предопределены спецификацией XBRL. Также, возможно определить собственные дуги. Но используется это обычно для технических целей, напр. для определения новых связей в расширении спецификации XBRL. Примером этого могут служить дуги, определенные в спецификации XBRL Dimensions, о которой мы поговорим в Главе 5.


3.1.4. Пример


Вернемся к примеру «таксономии»:


image

Здесь мы можем приблизительно определить следующие концепты:
Имя Тип
nr_employees_total non-negative integer item
nr_employees_male non-negative integer item
nr_employees_female non-negative integer item
nr_employees_age_up_to_20 non-negative integer item
nr_employees_age_21_to_40 non-negative integer item
nr_employees_age_41_and_up non-negative integer item


Мы рассмотрим эти концепты в следующем разделе про базы ссылок.

3.2. Базы ссылок


Определенные в схеме таксономии концепты являются минимально необходимыми строительными блоками таксономии. Они содержат точные данные о том, какие факты могут быть переданы в составе отчета XBRL.


Базы ссылок расширяют это определение следующим образом:


  • Позволяют разрабатывать определения с дополнительной документацией, напр. дают человекочитаемые метки или ссылки на нормативную литературу;
  • Описывают структуру концептов с внутренними связями между концептами, напр. определяя правила расчета;

Давайте сначала рассмотрим некоторые возможные базы ссылок для «таксономии» из нашего примера, чтобы понять, что они из себя представляют.

Примечание: Приведенные здесь «базы ссылок» не являются полными или корректными. Они приведены просто для иллюстрации.

База ссылок ярлыков (label linkbase)
База ссылок ярлыков может присвоить русский ярлык каждому используемому в форме концепту:
Концепт Ярлык
nr_employees_total Всего
nr_employees_male Мужчины
nr_employees_female Женщины


Другая база ссылок ярлыков может использоваться для присвоения английских ярлыков концептам:
Концепт Ярлык
nr_employees_total Total
nr_employees_male Men
nr_employees_female Women


Примечание: Этот пример базы ссылок ярлыков не совсем корректен. Мы вернемся к нему позже.

База ссылок определений (definition linkbase)
Определения концептов предоставляют различного рода информацию. Например, о том, что определенный концепт требует обязательного наличия другого концепта:
Концепт Требует
nr_employees_male nr_employees_female
nr_employees_female nr_employees_male


Если вы указываете факт по количеству мужчин, вы также должны указать факт по количеству женщин, и наоборот.

Если бы был определен концепт nr_employees, база ссылок определений могла бы указать, что он является аналогом всех nr_employees… концептов:
Концепт Псевдоним
nr_employees nr_employees_total
nr_employees nr_employees_male
nr_employees nr_employees_female


База ссылок вычислений (calculation linkbase)
C помощью вычисления можно задавать такие правила:
  • nr_employees_male + nr_employees_female = nr_employees_total


Такое правило автоматически отловило бы арифметическую ошибку в заполненной форме.

База ссылок на ресурсы (reference linkbase)
Предположим, что таксономия описывает отчет, требуемый законодательством. Полное описание того, что именно требуется предоставить, детально указано в законодательном акте, напр. как именно отчитываться по сотрудникам с частичной занятостью. База ссылок на ресурсы позволяет связать концепт с соответствующим ему разделом законодательного акта:
Концепт Ресурс
nr_employees_total Законодательный акт; Часть IV; Раздел 156-32.г
nr_employees_male Законодательный акт; Часть IV; Раздел 156-32.г
nr_employees_female Законодательный акт; Часть IV; Раздел 156-32.г


Примечание: Это можно выразить и связью «многие-к-одному», рассмотрим это далее.

База ссылок на презентаций (presentation linkbase)
Презентации описывают, как концепты могут быть иерархически представлены в отчетной форме. Наш пример мог бы иметь следующую иерархию:
Концепт Нижний уровень иерархии
nr_employees_total nr_employees_male
nr_employees_total nr_employees_female


3.2.1. Общие характеристики баз ссылок


Когда вы начнете углубляться в базы ссылок, вы увидите, что они обладают множеством общих характеристик. Рассмотрим некоторые из них.


3.2.1.1. Дуги (arcs)

Все базы ссылок используют дуги для описания взаимосвязей между концептами и их ресурсами или между разными концептами. Дуга представляет собой двустороннюю направленную связь, т.е. она указывает от одной стороны к другой. Каждая из сторон может состоять из одного или нескольких концептов или ресурсов.


В нашем примере базы ссылок на ресурсы мы можем использовать дугу вида «многие-к-одному», чтобы связать все три концепта одной ссылкой:

image

Атрибуты дуги from и to могут быть ресурсами, включенными в расширенную ссылку (extended link), или локаторами (locators) в расширенной ссылке, которые указывают на концепты или ресурсы в других документах.

Локатор указывает на концепт или ресурс с помощью атрибута href, который может содержать id концепта или выражение стандарта XPointer.

3.2.1.2. Запрет и переопределение

Когда таксономия расширяется, может потребоваться изменить существующие взаимосвязи между концептами. Для этого существует два механизма – запрет (prohibiting) и переопределение (overriding).


Дуга может иметь атрибут «приоритет». Когда у нескольких дуг случается «конфликт», преобладает та, что имеет наивысший приоритет, фактически переопределяя остальные дуги.


Если существующая дуга больше недействительна, можно добавить запрещающую дугу в свою базу ссылок с более высоким приоритетом, чем существующая. Запрещающей дугой является та, у которой необязательный атрибут use имеет значение prohibit.


При применении правил запрета и переопределения «базовая» сеть взаимосвязей изменяется расширениями. С использованием приоритета могут быть добавлены новые взаимосвязи, удалены существующие, либо существующие заменены новыми.

Спецификация XBRL указывает, что правила применяются к эквивалентным отношениям, и точно определяет, когда отношения эквивалентны на основе атрибутов дуг и сторон «от» и «к».

3.2.1.3. Циклы

Дуги образуют сеть взаимосвязей. Сеть может становиться очень сложной. Циклы внутри сети возникают, когда есть два или более путей от одного узла к другому. Таксономия должна указывать, какие из циклов разрешены:


  • Любые (any) – все циклы разрешены, нет ограничений на взаимосвязи;
  • Неориентированные (undirected) – этот странно названный вариант допускает циклы, если нет обратного пути к начальному узлу. Например, узлы А и Б могут иметь много путей от А к Б, но не должно быть пути от Б к А;
  • Никакие (none) – не разрешены никакие циклы, сеть не может иметь более одного пути между двумя узлами. Это накладывает большие ограничения на взаимосвязи.

Примечание: Путь состоит из набора дуг между узлами. Путь может быть коротким (одна дуга между двумя узлами) или длинным (сотни дуг между сотнями узлов).


3.2.1.4. Роли

Каждая ссылка в базе ссылок может иметь одну из нескольких ролей. Роль определяет использование ссылки. Доступные роли зависят от типа базы ссылок, они описаны в следующем разделе.


Как было сказано ранее, спецификация XBRL предоставляет набор ролей «общего назначения» для каждого типа базы ссылок. Вместо них возможно определить свои, более специфичные роли.


Роли могут быть использованы в ресурсах и в дугах между ними.


3.2.2. Специфичные характеристики баз ссылок


Хотя разные базы ссылок выглядят очень похожими по структуре, в них есть и различия. В этом разделе описываются характеристики, специфичные для каждого из типов баз ссылок.


3.2.2.1. База ссылок ярлыков

Ярлыки предоставляют человекочитаемый текст на определенном языке. Каждый ресурс должен идентифицировать используемый в ярлыке язык.


Ярлыки могут иметь следующие роли:


  • label (роль по умолчанию) – используется для стандартных ярлыков;
  • terseLabel – используется для сокращенных ярлыков, где часть описания опущена;
  • verboseLabel – используется для расширенных меток, подробно описывающих концепт;
  • positiveLabel, positiveTerseLabel и positiveVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для положительного значения факта;
  • negativeLabel, negativeTerseLabel и negativeVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для отрицательного значения факта;
  • zeroLabel, zeroTerseLabel и zeroVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для нулевого значения факта;
  • totalLabel – используется для ярлыков концептов, определяющих итоговые значения;
  • periodStartLabel и periodEndLabel – используются для ярлыков концептов, определяющих факты, ассоциированные с началом или окончанием периода;
  • documentation – для ярлыков, предоставляющих документацию по концепту;
  • definitionGuidance, disclosureGuidance, presentationGuidance, measurementGuidance, commentaryGuidance и exampleGuidance – для ярлыков, которые дают пояснения по таким аспектам концепта как определение, способ измерения или пример заполнения.

Дуга ярлыков имеет роль «concept-label», которая означает, что она всегда указывает от концепта к ярлыку. Поэтому дуги ярлыков никогда не образуют циклических связей между концептами.


Учитывая все вышесказанное, теперь мы можем более точно определить базу ссылок ярлыков из нашего примера:
Концепт Язык Роль Ярлык
nr_employees_total ru totalLabel Всего
nr_employees_male ru terseLabel Мужчины
nr_employees_female ru terseLabel Женщины
nr_employees_total en totalLabel Total
nr_employees_male en terseLabel Men
nr_employees_female en terseLabel Women


3.2.2.2. База ссылок ресурсов

Ссылки дают возможность связать определения концептов с положениями, опубликованными в деловой, финансовой и бухгалтерской литературе. Элемент должен предоставлять только ту информацию, которая необходима для идентификации и поиска соответствующей публикации. Он никогда не должен содержать текст самой публикации.


Ссылки могут состоять из частей (part), напр. «Законодательный акт; Часть IV; Раздел 156-32.г». В спецификации XBRL элемент part является абстрактным, поскольку способ разделения публикации на части варьируется для каждой публикации / юрисдикции.

Ссылки могут иметь следующие роли:


  • reference (значение по умолчанию) – используется для стандартного ресурса концепта;
  • definitionRef – используется для ссылки на точное определение концепта;
  • disclosureRef, mandatoryDisclosureRef и recommendedDisclosureRef – используются для ссылки на объяснения требований к раскрытию;
  • unspecifiedDisclosureRef – используется для ссылки на объяснения не указанных требований к раскрытию, таких как общая практика, полнота и структура;
  • presentationRef – используется для ссылки на объяснение презентации концепта;
  • measurementRef – используется для ссылки на метод измерения значения концепта;
  • commentaryRef – используется для ссылки на любой комментарий общего плана к концепту;
  • exampleRef – используется для ссылки на документацию, иллюстрирующую использование концепта с помощью примера.

Дуга ресурсов имеет роль «concept-reference», которая означает, что она всегда указывает от концепта к ресурсу. Поэтому дуги ресурсов никогда не образуют циклических связей между концептами.


3.2.2.3. База ссылок презентаций

Дуги презентаций имеют роль «parent-child», что позволяет определять иерархическую структуру концептов. И parent-, и child-сторона связи должна указывать на концепт.


Когда нет концепта, который мог бы естественным образом выступать в качестве корня иерархии презентации, вместо него можно использовать абстрактный концепт, специально определенный для этой цели.


Дуга может иметь атрибут preferredLabel, который идентифицирует предпочтительную роль метки для указания на child-концепте презентации. Это особенно полезно, когда концепт используется несколько раз по-разному в DTS. Каждая связь в презентации может указывать на отдельную метку (в соответствии с ее ролью) для использования по этому концепту.


Для определения порядка следования концептов в презентации может использоваться атрибут дуги order.


3.2.2.4. База ссылок вычислений

Дуги вычислений имеют роль «summation-item», представляющую суммирующие взаимосвязи между концептами (вычитание в этом случае обеспечивается суммированием концепта, умноженного на -1, см.далее). Связь указывает от суммирующего концепта к нескольким суммируемым концептам. Дуга вычислений может соединять только item-концепты.


Вычисления возможны только по концептам, эквивалентным по контексту и единице измерения.


Примечание: Отношения, заданные кортежами, также играют роль в вычислениях. Например, невозможно выполнять суммирование по элементам дублирующихся кортежей.


Дуга вычисления имеет атрибут weight, который используется как коэффициент умножения для суммируемого значения. Это позволяет осуществлять более сложные вычисления, чем простое сложение. В момент умножения выполняется необходимое округление.


В DTS учитывается полная совокупность вычислений. Все вычисления с одной и той же ролью по одному и тому же концепту будут выполнены в полном объёме. Если в одном отчете присутствует несколько детализаций одного и того же значения, каждое из его вычислений должно иметь свою собственную роль. В противном случае все вычисления будут суммированы вместе, что приведет к задвоению, затроению и т.д. результирующего значения.


Отчет XBRL считается корректным относительно базы ссылок вычислений, если все вычисления в пределах этого отчета согласованы. Это позволяет выполнять автоматическую проверку вычислений.


Возможности, предоставляемые базой ссылок вычислений, достаточно ограничены.

Можно выполнять более сложные вычисления, чем простое сложение, но это непросто, и даже в этом случае ограничения являются довольно серьезными. Например, невозможно вычислить разницу между фактами по одному и тому же концепту, но в разных контекстах, скажем, на начало и на конец периода.

В настоящее время разрабатывается еще одна база ссылок – формулы (formula linkbase). Она станет доступна для использования в ближайшее время и обеспечит более широкие функциональные возможности для определения формул расчета.

3.2.2.5. База ссылок определений

Дуга определений может иметь следующие роли, обозначающие разные виды взаимосвязей:


  • general-special
    Взаимосвязь item-концептов с их обобщением / детализацией. Такие взаимосвязи можно рассматривать как «является одним из», напр. концепт «менеджер подразделения» является детализацией концепта «менеджер». Обратите внимание, что любое допустимое значение для элемента детализации также является допустимым как значение для элемента обобщения. В обратную сторону это, как правило, не работает.
    Сеть таких взаимосвязей может содержать только неориентированные циклы, поскольку детализация никогда не может быть собственным обобщением.
  • essence-alias
    Эта взаимосвязь может быть применена только к item-концептам. Она используется, когда определены несколько похожих концептов и указывает, какой из них является наиболее подходящим (essence). Все остальные концепты считаются псевдонимами (alias) этого essence-концепта.
    Alias-концепты и essence-концепты должны иметь одинаковый тип значения, одинаковый тип периода (periodType) и одинаковый атрибут balance, если он используется.
    Сеть таких взаимосвязей может содержать только неориентированные циклы, поскольку концепт не может быть собственным псевдонимом.
  • similar-tuples
    Эта взаимосвязь используется между кортежами концептов и аналогична essence-alias для item-концептов – она идентифицирует кортежи с эквивалентными определениями. Примером может служить почтовый адрес, который может отражаться в разных форматах, но содержать эквивалентные данные.
  • requires-element
    Эта взаимосвязь используется между кортежами или item-концептами и определяет требования в пределах отчета XBRL. Если в отчете используется факт для концепта на стороне «от», то в отчете также обязательно должен быть факт для концепта на стороне «к».




Поделиться с друзьями
-->

Комментарии (0)