6.6. Многомерность

Гиперкубы с одним измерением не представляют никакой проблемы, не так ли? В этой заключительной главе давайте посмотрим, как будут выглядеть таксономия измерений и отчет, если мы объединим два измерения в один гиперкуб.

Это приведет к изменениям во всех частях таксономии – в основном, к отбрасыванию элементов, которые больше не нужны, и замене нескольких элементов на один комбинированный:

• Базовые концепты
  Теперь нам не нужно различать два измерения, поэтому мы можем избавиться от концептов nr_employees_by_age и nr_employees_by_gender.
• Таксономия измерений
  Поскольку мы можем использовать элемент gender для обозначения “всех гендерных групп”, аналогично добавим элемент all в тип age_group_type.

6.5. Новые измерения

В предыдущих разделах мы достигли значительных успехов в представлении отчетной формы из нашего примера в виде отчета XBRL, но полного соответствия так и не получили. Сегодня на одного из наших разработчиков снизошло озарение: А давайте попробуем применить XBRL Dimensions!

При взгляде на Главу 5 становится очевидно, что гендерные и возрастные группы могут быть представлены в виде измерений.

Базовая таксономия, создаваемая нами до сих пор, достигла версии sample-2006-01-05.xsd. Мы определим элементы доменов (domain member) и шаблоны (template) в отдельной таксономии sample-2006-01-05-dimension.xsd.

6.4. Как облегчить жизнь

До сих пор мы использовали только простые item-концепты. Каждый из nr_employees-концептов мог быть интерпретирован независимо от остальных.

У такого подхода есть недостаток: если количество полов обычно ограничивается двумя, то для возраста мы могли бы иметь большее количество групп, чем три в нашем примере. Что, если бы нам понадобилось разделить возраста на 10-летние интервалы? Пришлось бы добавить новые концепты для групп 11–20, 21–30, 31–40, 41–50, 51–60 и 61–70. А при делении на 5-летние, 2-летние или даже годовые интервалы это очень быстро станет утомлять. Базы ссылок стали бы очень большими, поскольку надо было бы определять ссылки для каждого из этого множества концептов. Хотелось бы иметь более эффективный подход для подобных ситуаций.

И сегодня мы расскажем, как нам в этом могут помочь кортежи.

6.3. Вычисления и валидация

Теперь, когда у нас есть таксономия, позволяющая построить неплохой отчет, настало время приступить к решению ещё одного вопроса – валидация.

Как вы помните, в нашей компании работает один ‘одаренный’ математик. Несмотря на то, что отчет в целом выглядит хорошо, 27 мужчин и 15 женщин никак не могут дать общее количество сотрудников, равное 41.

К счастью, в XBRL есть решение на такой случай – базы ссылок вычислений (calculation linkbases).

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

Нам нужно внести несколько изменений в схему таксономии, чтобы начать использовать базу ссылок вычислений:

• Определить связь с базой ссылок;
• Разрешить использование необходимых ролей.

6.2. Совершенствуем результат

Вчера мы были вполне довольны полученным результатом. Но вот мы хорошо выспались и осознали, что это пока ещё не совсем то, что мы хотели бы получить.

Отчетная форма в нашем примере содержала несколько разделов – для итоговых значений, а также для группировки по полу и возрастным группам. И у нее не было этого безобразного заголовка ‘http://www.xbrl.org/2003/role/link’ в верхней части отчета.

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

Итак, первым делом нам надо настроить разделы отчета с заголовками, которые хоть что-то означают.

6. Погружение в XBRL

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

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

Примечание: Мы не будем создавать базы ссылок определений (definition linkbase) и базы ссылок на реcурсы (reference linkbase). В реальной жизни вы могли бы создать по крайней мере одну из них, чтобы более подробно описать свои концепты, но для целей данной главы они не нужны. После того, как вы освоите базы ссылок ярлыков (label linkbase) и презентаций (presentation linkbase), с пониманием баз ссылок определений и ресурсов не должно возникнуть никаких проблем.

6.1. Приступаем

Начнем с простой таксономии для нашего примера.

5. Открывая новые измерения

Предыдущие главы показали вам, что такое XBRL, и что с его помощью можно сделать. Как вы уже знаете, он является расширяемым стандартом. В этой главе мы рассмотрим один из расширяющих стандартную спецификацию модулей – XBRL Dimensions (Измерения).

Глава основывается на спецификации XBRL Dimensions версии 1.0 CR от 19.06.2006. На момент написания книги спецификация находится в статусе Candidate Recommendation, но ожидается, что окончательный вариант не принесет никаких значительных сюрпризов.

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

5.1. Введение

Обычно, факты в отчетах некоторым образом классифицируются, например:

• Продажи в разных периодах;
• Продажи по продуктовым линиям;
• Продажи по регионам;
• Продажи по отделам;
• Количество сотрудников по возрасту;
• Количество сотрудников по полу;
• ...

4. Отчет XBRL

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

Отчет (instance document) содержит факты и ссылается на таксономию для придания фактам смысла:

Факты могут быть простыми (item) или составными (кортеж, tuple). Все простые факты в отчете имеют контекст, напр. финансовый год или начало отчетного периода. Все используемые контексты содержатся в самом отчете.

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

В следующих разделах мы более подробно рассмотрим составные части отчета.

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

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

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

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

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

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

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

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

2. Что такое XBRL?

Прежде чем погрузиться в спецификацию XBRL, в этой главе вкратце рассмотрим, что же такое ​​XBRL. Как объяснялось в предыдущей главе, XBRL фактически представляет собой две вещи: определение того, что нужно включить состав отчета и сами отчётные данные. Вам будут представлены обе части XBRL: таксономии и отчеты.

2.1. Что такое таксономия?

Помните пример отчетной формы, которую я показал в первой главе? Вот она снова:

Комментарий от переводчика

В 2015 году Центральный Банк РФ запустил проект перехода некредитных финансовых организаций (НФО) на электронный формат представления отчетных данных в формате XBRL с 01.01.2018. Сроки уже подходят, а НФО только начинают осознавать масштабы грядущих изменений. Качественных материалов про XBRL на русском языке достаточно мало (могу разве что рекомендовать книгу XBRL для чайников, перевод которой был инициирован ЦБ, правда выполнен не в лучшем виде). Хочу восполнить этот пробел и предлагаю вашему вниманию свою адаптацию неплохой брошюры XBRL in Plain English от компании Batavia, которая рассказывает об основах XBRL.

Перевод веду от лица автора, немного дополняю текст полезными ссылками. Стараюсь придерживаться терминологии ЦБ РФ со ссылкой на оригинальные термины. Начну с первых глав, и если тема будет вам интересна, завершу перевод. Комментируйте, задавайте вопросы − расскажу все, что знаю.

Роман Удальцов

---

1. Введение

В этой главе представлена сама книга и основные понятия XBRL

1.1. Что ожидать

Если вы начали читать эту книгу, значит вы уже слышали о новом способе формирования бизнес-отчетности − XBRL. Если вы взглянули на спецификацию XBRL, то знаете, что она представляет собой 158-страничный документ, полный формальных определений. Такой документ нужен для корректного определения XBRL. Его можно считать расслабляющим чтивом на ночь для математиков. Но не для нас, нормальных людей.

Меня всегда привлекала тема личных финансов. Экспериментировал с различными финансовыми инструментами — обезличенными металлическими счетами, фондовым рынком, паевыми инвестиционными фондами, даже ПАММ-счетами баловался. Много времени и денег на это не тратил, больше ради интереса и для общего развития.

Знакомство с криптовалютами началось в конце 2013 года. Почитал публикации про Сатоши, алгоритмы, майнинг и перспективы инвестиций в bitcoin — и решил рискнуть. В то время btc как раз взлетал в небеса, дразня воображение. Зарегистрировался на btc-e.com и закупился. Как водится, сразу после этого всё вдруг стало плохо :)


Глядя на падающий в течение первого года курс я грустил, лениво и не всегда удачно жонглировал с ltc, nvc, nmc, а потом и вовсе бросил оставшиеся средства на произвол судьбы.

В конце 2016 года мне на глаза попалась статья про HashFlare.