По большей части да, но базовые вещи для общего понимания тут тоже присутствуют. Статьи не мои, кстати, это перевод, ссылка на оригинал — под заголовком каждого поста.
Книжка же не про бури, а про находчивый инженерный ум и конечно про здоровый юмор. К тому же, в процессе прочтения оригинала столько новых вопросов и мыслей появляется, что «для справки» изучаешь сравнимый с книжкой объём самых разнообразных публикаций. В моем книжном рейтинге по полученному от прочтения удовольствию пока даже близко к Марсианину ничего не стояло. Фильм не передаёт вот это все, разумеется.
«Yes, the RTG. You may remember it from my exciting trip to Pathfinder. A lovely lump of plutonium so radioactive it gives off 1500 watts of heat, which it uses to harvest 100 watts of electricity. So what happens to the other 1400 watts? It gets radiated out as heat.»
Не книжка, а чистое удовольствие, спасибо за напоминание :)
Концепты (некоторые называют их показателями) содержатся в таксономии.
В отчете XBRL есть только ссылки на таксономию, контексты и факты.
Элементы всех измерений – как закрытых, так и открытых – указываются в контекстах отчета XBRL. Разница лишь в том, что для закрытых измерений приводится ссылка на определенный в таксономии элемент, а для открытых – само значение элемента.
Для этого измерения мы явно задаем значение элемента, при этом, его тип данных можно посмотреть в элементе, указанном в атрибуте xbrldt:typedDomainRef определения измерения – #dim-int_ID_YULTypedName:
Это читается примерно следующим образом (опустим поиски ярлыка концепта): Сумма просроченных, но не обесцененных средств со сроком задержки платежа менее 30 дней по предоставленным займам по данным бухгалтерского учета на конец отчетного периода (всего) составляет 1 руб.
Разве сегмент НСО (надзорно-статистическая отчётность) таксономии НФО входит в состав передаваемых через Пикософт данных? (сам не знаю, поэтому спрашиваю) Даже если входит, Table linkbase я видел пока только в БФО сегменте.
НСО частично заполняется из счетов ЕПС и символов ОФР (но и там есть нюансы вроде разбивки счета/символа на несколько концептов по дополнительным аналитическим признакам. Кроме того есть концепты, факты по которым формируются только вручную (вроде Среднесписочной численности).
Так или иначе, основная моя мысль была в том, что прежде чем использовать XBRL-коробку (будь то новый модуль бухгалтерской учётной системы или АБС, либо отдельные решения вроде упомянутого вами конвертера), надо потратить немало времени на анализ соответствий между формами Пикософта/данными в системах компании и конвертами своей точки входа таксономии.
Да, под аналогом Arelle я имел в виду SXV XBRL Viewer.
В Пикософт данные заводятся по большей части вручную, хоть процесс их подготовки и может быть частично автоматизирован. Объем данных не очень большой, передаваемые через Пикософт формы бухгалтерия знает наизусть.
С XBRL ситуация сложнее – объем данных несоизмеримо больше и надо внимательно разбираться, как правильно привязать данные компании к концептам таксономии. Это внушительный объем методологической работы, который ложится либо на плечи бизнес-аналитиков компании, либо отдается на аутсорс.
Техническая сторона вопроса – конвертация массива отчетных данных в привязанный к таксономии XBRL-отчет – выглядит сравнительно проще.
Тем компаниям, у которых развернуты серьезные решения по бух.учету, будет немного проще, т.к. вендоры действительно могут добавить XBRL-модуль и обеспечить методологическую поддержку в рамках находящихся в системе данных – однако, это покрывает только часть концептов, и даже в этом случае останутся тысячи концептов, по которым необходим методологический анализ и какая-то техническая работа (скорее всего, согласованный с вендором способ ввода в модуль XBRL недостающих данных).
P.S. Указанный вами проект видимо не очень активен – выложена пара утилит (менее функциональный аналог Arelle и какой-то конвертер), перепост новостей.
Банк России опубликовал предварительную версию финальной таксономии бухгалтерской (финансовой), надзорной и статистической отчетности страховых организаций, негосударственных пенсионных фондов и профессиональных участников рынка ценных бумаг для их перехода на XBRL (eXtensible Business Reporting Language, расширяемый язык деловой отчетности).
В ближайшее время регулятор опубликует также программное обеспечение, которое позволит преобразовывать отчетные данные в формат XBRL с использованием этой таксономии и формировать в нем пакет отчетности. Таким образом, участники рынка смогут протестировать процесс формирования пакета отчетности.
Предварительная версия финальной таксономии разработана на основе модели данных и форм отчетности, публиковавшихся ранее. При этом ее структура и содержание максимально приближены к содержанию финальной таксономии, которую планируется опубликовать осенью 2017 года.
С 1 января 2018 года вводится обязательное использование формата XBRL для сбора и обработки отчетности страховых организаций, негосударственных пенсионных фондов, участников рынка ценных бумаг и управляющих компаний паевых и акционерных инвестиционных фондов.
Вы очень точно обозначили складывающуюся ситуацию. XBRL покажет, насколько качественные ИТ-решения и процессы имеет каждая из компаний. Для НФО, у которых нет крутых core-систем (далеко не все крупные НФО решаются на их внедрение) это будет видно особенно отчётливо.
Если сильно упрощать, то XBRL выдвигает новые требования к собираемым данным, значительно более широкие, чем было до сих пор; и у тех компании, где бизнес- и системный анализ, сбор и обработка данных отлажены как швейцарский хронометр, не составит большого труда удовлетворить эти требования, ведь завернуть готовые данные в xml нужного вида – технически несложная задачка. Остальным же предстоит колоссальный объём методологической и технической работы по созданию процессов подготовки данных для передачи в ЦБ. Про Excel и ручной ввод можно сразу забыть – счёт идёт на десятки тысяч значений ежемесячно.
Но самое печальное то, что ЦБ уже год кричит на всех углах про XBRL, про то, что всем давно пора бросать все и заниматься проектом, а то не никак успеть к концу года – но многие компании до сих не в курсе происходящего. Что ж, как говорится – держитесь там!
Всё так, кредитные финансовые организации будут переводить на XBRL после НФО, не ранее 2019 года, а может и позже. Я как сотрудник страховой компании немного завидую вам в этом плане :)
Возможно, у вас есть более достоверный источник информации, чем ЦБ РФ, но на последней встрече в ЦБ, как и на всех предыдущих встречах, моментом перехода страховых, НПФ, ПУРЦБ, инвестиционных фондов на предоставление отчетности в формате XBRL обозначалась дата 01.01.2018.
Самые свежие материалы на сайте проекта – Презентация с заседания рабочей группы от 11.07.2017 (чуть более недели назад). План проекта вы можете найти на слайде 3, на нем отчетливо видна Подготовка отчетности в формате XBRL с начала 2018 года. В первых числах августа будет опубликован нормативный акт, регулирующий все вопросы подготовки отчетности в формате XBRL. Уверяю вас, в нем будут указаны те же самые сроки.
Срок перехода на XBRL с 01.01.2019 установлен только для несущественной части НФО, включающей в себя страховых брокеров, спецдепы, микрофинансовые организации, ломбарды и т.д., подробнее см. слайд 11 здесь.
Совершенно верно, раньше отчеты собирались разными ведомствами и, что важно, в виде фиксированных отчетных форм.
Теперь же участники финансового рынка будут передавать в ЦБ лишь полный набор фактов, из которых ЦБ на своей стороне соберет любую из отчетных форм (порядок визуализации отчетных данных в виде форм заложен в таксономию с помощью presentation linkbase, об этом будет рассказываться в следующих главах).
ЦБ, являясь регулятором финансового рынка РФ, в соответствии со стандартом XBRL разрабатывает Таксономию.
Таксономия публикуется на официальном сайте ЦБ и регламентирует, какие именно данные и как часто должны передаваться финансовыми организациями в ЦБ в составе Отчетов XBRL.
Отчет XBRL в техническом смысле представляет из себя приличных размеров (до нескольких Гб) xml-документ с данными (фактами), ссылающимся на элементы (концепты) таксономии.
Кошмарить будут не только мелкий и средний бизнес, а всех участников некредитного (а позже видимо и кредитного) финансового рынка, включая крупнейшие банки, страховые, НПФ и т.д. – но не чаще, чем дважды в год. Регламент внесения изменений в таксономию обозначен, к примеру, на слайде 12 этой презентации.
В расчёты ее заложить напрямую не получится, но она непосредственно влияет на суммы выплат (и не только она), они влияют на ставку HF, а она влияет на оценку доходов/сроков. Да, со временем сложность растёт, доход снижается, сроки увеличиваются.
Полезным упражнением будет ежемесячный пересчёт всех оценок для отслеживания динамики.
Можно прикинуть «банковскую» среднегодовую процентную ставку.
Для удобства введём следующие обозначения:
inv – вложения в хэшрейт HashFlare (investment) int – рассчитанный выше среднегодовой процент возврата вложений (interest) days – период в днях
Тогда, сумма выплат за период (пренебрегаем високосными годами): inv × int × days / 365
Вычитая вложения, получаем прибыль: inv × int × days / 365 – inv
Поделив прибыль на сумму вложений, получаем ту самую «банковскую» процентную ставку за период: (inv × int × days / 365 – inv) / inv = int × days / 365 – 1
Остаётся привести результат к году: (int × days / 365 – 1) × 365 / days = int – 365 / days
Для SHA-256 ставка HF получилась 103,16%. Значит, если бы HashFlare закрылся в день моих расчетов (по прошествии 83 дней от покупки хэшрейта), то «банковская» ставка составила бы: 1,0316 – 365 / 83 = –336,6%
Если HashFlare проработает, скажем, 3 года, то при той же средней ставке HF «банковская» ставка получится: 1,0316 – 365 / (3 × 365) = 69,8%
Точка окупаемости SHA-256, после которой «банковская» процентная ставка перестает быть отрицательной и начинает расти в плюс: 1,0316 – 365 / x = 0; x = 365 / 1,0316 = 354 дня
Для обгона максимальной ставки по депозитам (возьму для примера 20%) требуется: 1,0316 – 365 / x = 0,2; x = 365 / 0,8316 = 439 дней
Аналогично, точка окупаемости Scrypt: x = 365 / 0,863 = 423 дня
Обгон депозитов для Scrypt: x = 365 / 0,663 = 551 день
Очень много допущений для точных расчетов (ставка HF постоянно меняется), но принцип оценки понятен.
int, % — interest, показывает, какую часть стоимости единицы мощности даст return за 365 дней, назовем это «годовой процент», но не забываем, что, в отличие от банковского депозита, из полученной суммы надо еще вычесть вложения
HF удерживает фиксированную сумму 0,0003 btc (19,95 руб. по текущему курсу), cryptopay с меня не взял ни копейки, pay-x.cc – около 2–3%. Не могу назвать это большой комиссией.
Статьи не мои, кстати, это перевод, ссылка на оригинал — под заголовком каждого поста.
Книжка же не про бури, а про находчивый инженерный ум и конечно про здоровый юмор. К тому же, в процессе прочтения оригинала столько новых вопросов и мыслей появляется, что «для справки» изучаешь сравнимый с книжкой объём самых разнообразных публикаций. В моем книжном рейтинге по полученному от прочтения удовольствию пока даже близко к Марсианину ничего не стояло. Фильм не передаёт вот это все, разумеется.
Эти фотки я находил в процессе прочтения. Интересно было как раз сами таблетки увидеть)
«Yes, the RTG. You may remember it from my exciting trip to Pathfinder. A lovely lump of plutonium so radioactive it gives off 1500 watts of heat, which it uses to harvest 100 watts of electricity. So what happens to the other 1400 watts? It gets radiated out as heat.»
Не книжка, а чистое удовольствие, спасибо за напоминание :)
Концепты (некоторые называют их показателями) содержатся в таксономии.
В отчете XBRL есть только ссылки на таксономию, контексты и факты.
Элементы всех измерений – как закрытых, так и открытых – указываются в контекстах отчета XBRL. Разница лишь в том, что для закрытых измерений приводится ссылка на определенный в таксономии элемент, а для открытых – само значение элемента.
Покажу на примере от ЦБ.
Скачайте Сопроводительные документы модуль НСО ССД с сайта ЦБ.
Откройте пример отчета XBRL – демонстрационный инстанс\ep_nso_ins_m.xbrl.
Начнем с закрытого (explicit) измерения.
Найдите контекст
sr_154_Instant_Menee30DnejMember
(строка 46):Здесь мы видим измерение
Summa_Prosr_Neobescz_Sredstv_Srok_Zaderzh_Plat_Axis
и ссылку на его элементMenee30DnejMember
.Чтобы получить больше информации по ним, скачайте таксономию с той же страницы на сайте ЦБ (Предварительная версия финальной таксономии XBRL Банка России) и разархивируйте ее.
Откройте документ \www.cbr.ru\xbrl\udr\dim\dim-int.xsd и найдите в нем измерение из нашего примера (строка 437):
Это определение самого измерения. Ярлык для этого измерения на русском языке можно найти в соседнем документе dim-int-label.xsd (строка 1321):
Сами значения измерения определены в документе \www.cbr.ru\xbrl\udr\dom\mem-int.xsd (строка 98):
Ярлыки значений – в соседнем документе mem-int-label.xml (строка 274):
Теперь вернемся в демонстрационный инстанс\ep_nso_ins_m и посмотрим на открытые (typed) измерения. Найдите контекст
sr_154_Duration_1_1
(строка 13):Здесь видно два измерения –
IdZaemshhikaTaxis
иIdZajmaTaxis
.Разберем первое из них, со вторым все совершенно аналогично.
Само измерение определено все в том же dim-int.xsd (строка 385):
Ярлык, соответственно, в dim-int-label.xsd (строка 1066):
Для этого измерения мы явно задаем значение элемента, при этом, его тип данных можно посмотреть в элементе, указанном в атрибуте
xbrldt:typedDomainRef
определения измерения –#dim-int_ID_YULTypedName
:Как видим, тут строковый тип. Ему вполне соответствует указанное в контексте отчета значение элемента измерения –
1
.Контексты с указанными в них элементами измерений используются в том же ep_nso_ins_m.xbrl для передачи фактов (строки 156293 и 164251):
Это читается примерно следующим образом (опустим поиски ярлыка концепта):
Сумма просроченных, но не обесцененных средств со сроком задержки платежа менее 30 дней по предоставленным займам по данным бухгалтерского учета на конец отчетного периода (всего) составляет 1 руб.
Первоначальная стоимость по депозитам, выбывшим в течение отчетного периода для заемщика c ID 1 и займа с ID 1 составляет 1 руб.
НСО частично заполняется из счетов ЕПС и символов ОФР (но и там есть нюансы вроде разбивки счета/символа на несколько концептов по дополнительным аналитическим признакам. Кроме того есть концепты, факты по которым формируются только вручную (вроде Среднесписочной численности).
Так или иначе, основная моя мысль была в том, что прежде чем использовать XBRL-коробку (будь то новый модуль бухгалтерской учётной системы или АБС, либо отдельные решения вроде упомянутого вами конвертера), надо потратить немало времени на анализ соответствий между формами Пикософта/данными в системах компании и конвертами своей точки входа таксономии.
Да, под аналогом Arelle я имел в виду SXV XBRL Viewer.
С XBRL ситуация сложнее – объем данных несоизмеримо больше и надо внимательно разбираться, как правильно привязать данные компании к концептам таксономии. Это внушительный объем методологической работы, который ложится либо на плечи бизнес-аналитиков компании, либо отдается на аутсорс.
Техническая сторона вопроса – конвертация массива отчетных данных в привязанный к таксономии XBRL-отчет – выглядит сравнительно проще.
Тем компаниям, у которых развернуты серьезные решения по бух.учету, будет немного проще, т.к. вендоры действительно могут добавить XBRL-модуль и обеспечить методологическую поддержку в рамках находящихся в системе данных – однако, это покрывает только часть концептов, и даже в этом случае останутся тысячи концептов, по которым необходим методологический анализ и какая-то техническая работа (скорее всего, согласованный с вендором способ ввода в модуль XBRL недостающих данных).
P.S. Указанный вами проект видимо не очень активен – выложена пара утилит (менее функциональный аналог Arelle и какой-то конвертер), перепост новостей.
Банк России опубликовал предварительную версию финальной таксономии бухгалтерской (финансовой), надзорной и статистической отчетности страховых организаций, негосударственных пенсионных фондов и профессиональных участников рынка ценных бумаг для их перехода на XBRL (eXtensible Business Reporting Language, расширяемый язык деловой отчетности).
В ближайшее время регулятор опубликует также программное обеспечение, которое позволит преобразовывать отчетные данные в формат XBRL с использованием этой таксономии и формировать в нем пакет отчетности. Таким образом, участники рынка смогут протестировать процесс формирования пакета отчетности.
Предварительная версия финальной таксономии разработана на основе модели данных и форм отчетности, публиковавшихся ранее. При этом ее структура и содержание максимально приближены к содержанию финальной таксономии, которую планируется опубликовать осенью 2017 года.
С 1 января 2018 года вводится обязательное использование формата XBRL для сбора и обработки отчетности страховых организаций, негосударственных пенсионных фондов, участников рынка ценных бумаг и управляющих компаний паевых и акционерных инвестиционных фондов.
31 июля 2017 года
Если сильно упрощать, то XBRL выдвигает новые требования к собираемым данным, значительно более широкие, чем было до сих пор; и у тех компании, где бизнес- и системный анализ, сбор и обработка данных отлажены как швейцарский хронометр, не составит большого труда удовлетворить эти требования, ведь завернуть готовые данные в xml нужного вида – технически несложная задачка. Остальным же предстоит колоссальный объём методологической и технической работы по созданию процессов подготовки данных для передачи в ЦБ. Про Excel и ручной ввод можно сразу забыть – счёт идёт на десятки тысяч значений ежемесячно.
Но самое печальное то, что ЦБ уже год кричит на всех углах про XBRL, про то, что всем давно пора бросать все и заниматься проектом, а то не никак успеть к концу года – но многие компании до сих не в курсе происходящего. Что ж, как говорится – держитесь там!
Возможно, у вас есть более достоверный источник информации, чем ЦБ РФ, но на последней встрече в ЦБ, как и на всех предыдущих встречах, моментом перехода страховых, НПФ, ПУРЦБ, инвестиционных фондов на предоставление отчетности в формате XBRL обозначалась дата 01.01.2018.
Самые свежие материалы на сайте проекта – Презентация с заседания рабочей группы от 11.07.2017 (чуть более недели назад). План проекта вы можете найти на слайде 3, на нем отчетливо видна Подготовка отчетности в формате XBRL с начала 2018 года. В первых числах августа будет опубликован нормативный акт, регулирующий все вопросы подготовки отчетности в формате XBRL. Уверяю вас, в нем будут указаны те же самые сроки.
Срок перехода на XBRL с 01.01.2019 установлен только для несущественной части НФО, включающей в себя страховых брокеров, спецдепы, микрофинансовые организации, ломбарды и т.д., подробнее см. слайд 11 здесь.
Теперь же участники финансового рынка будут передавать в ЦБ лишь полный набор фактов, из которых ЦБ на своей стороне соберет любую из отчетных форм (порядок визуализации отчетных данных в виде форм заложен в таксономию с помощью presentation linkbase, об этом будет рассказываться в следующих главах).
ЦБ, являясь регулятором финансового рынка РФ, в соответствии со стандартом XBRL разрабатывает Таксономию.
Таксономия публикуется на официальном сайте ЦБ и регламентирует, какие именно данные и как часто должны передаваться финансовыми организациями в ЦБ в составе Отчетов XBRL.
Отчет XBRL в техническом смысле представляет из себя приличных размеров (до нескольких Гб) xml-документ с данными (фактами), ссылающимся на элементы (концепты) таксономии.
Кошмарить будут не только мелкий и средний бизнес, а всех участников некредитного (а позже видимо и кредитного) финансового рынка, включая крупнейшие банки, страховые, НПФ и т.д. – но не чаще, чем дважды в год. Регламент внесения изменений в таксономию обозначен, к примеру, на слайде 12 этой презентации.
Полезным упражнением будет ежемесячный пересчёт всех оценок для отслеживания динамики.
Такую оценку можно делать только на имеющихся данных по покупкам и операциям.
Для удобства введём следующие обозначения:
inv
– вложения в хэшрейт HashFlare (investment)int
– рассчитанный выше среднегодовой процент возврата вложений (interest)days
– период в дняхТогда, сумма выплат за период (пренебрегаем високосными годами):
inv × int × days / 365
Вычитая вложения, получаем прибыль:
inv × int × days / 365 – inv
Поделив прибыль на сумму вложений, получаем ту самую «банковскую» процентную ставку за период:
(inv × int × days / 365 – inv) / inv = int × days / 365 – 1
Остаётся привести результат к году:
(int × days / 365 – 1) × 365 / days = int – 365 / days
Получается довольно простая зависимость:
[«Банковская» годовая процентная ставка] =
[Годовая процентная ставка HashFlare] – 365 / [Период в днях]
Примерим к моим расчетам.
Для SHA-256 ставка HF получилась 103,16%. Значит, если бы HashFlare закрылся в день моих расчетов (по прошествии 83 дней от покупки хэшрейта), то «банковская» ставка составила бы:
1,0316 – 365 / 83 = –336,6%
Если HashFlare проработает, скажем, 3 года, то при той же средней ставке HF «банковская» ставка получится:
1,0316 – 365 / (3 × 365) = 69,8%
Точка окупаемости SHA-256, после которой «банковская» процентная ставка перестает быть отрицательной и начинает расти в плюс:
1,0316 – 365 / x = 0; x = 365 / 1,0316 = 354 дня
Для обгона максимальной ставки по депозитам (возьму для примера 20%) требуется:
1,0316 – 365 / x = 0,2; x = 365 / 0,8316 = 439 дней
Аналогично, точка окупаемости Scrypt:
x = 365 / 0,863 = 423 дня
Обгон депозитов для Scrypt:
x = 365 / 0,663 = 551 день
Очень много допущений для точных расчетов (ставка HF постоянно меняется), но принцип оценки понятен.
HF удерживает фиксированную сумму 0,0003 btc (19,95 руб. по текущему курсу), cryptopay с меня не взял ни копейки, pay-x.cc – около 2–3%. Не могу назвать это большой комиссией.
Намайненное небольшими порциями (раз в пару недель/месяц) выводится по текущему курсу в рубли, а не остаётся в btc.