Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Вот именно что Extensible — теперь контролирующие органы смогут менять формат отчётности так часто, как захотят. тем самым «кошмаря» мелкий и средний бизнес.
Совершенно верно, раньше отчеты собирались разными ведомствами и, что важно, в виде фиксированных отчетных форм.
Теперь же участники финансового рынка будут передавать в ЦБ лишь полный набор фактов, из которых ЦБ на своей стороне соберет любую из отчетных форм (порядок визуализации отчетных данных в виде форм заложен в таксономию с помощью presentation linkbase, об этом будет рассказываться в следующих главах).
Теперь же участники финансового рынка будут передавать в ЦБ лишь полный набор фактов, из которых ЦБ на своей стороне соберет любую из отчетных форм (порядок визуализации отчетных данных в виде форм заложен в таксономию с помощью presentation linkbase, об этом будет рассказываться в следующих главах).
XBRL – это лишь стандарт.
ЦБ, являясь регулятором финансового рынка РФ, в соответствии со стандартом XBRL разрабатывает Таксономию.
Таксономия публикуется на официальном сайте ЦБ и регламентирует, какие именно данные и как часто должны передаваться финансовыми организациями в ЦБ в составе Отчетов XBRL.
Отчет XBRL в техническом смысле представляет из себя приличных размеров (до нескольких Гб) xml-документ с данными (фактами), ссылающимся на элементы (концепты) таксономии.
Кошмарить будут не только мелкий и средний бизнес, а всех участников некредитного (а позже видимо и кредитного) финансового рынка, включая крупнейшие банки, страховые, НПФ и т.д. – но не чаще, чем дважды в год. Регламент внесения изменений в таксономию обозначен, к примеру, на слайде 12 этой презентации.
ЦБ, являясь регулятором финансового рынка РФ, в соответствии со стандартом XBRL разрабатывает Таксономию.
Таксономия публикуется на официальном сайте ЦБ и регламентирует, какие именно данные и как часто должны передаваться финансовыми организациями в ЦБ в составе Отчетов XBRL.
Отчет XBRL в техническом смысле представляет из себя приличных размеров (до нескольких Гб) xml-документ с данными (фактами), ссылающимся на элементы (концепты) таксономии.
Кошмарить будут не только мелкий и средний бизнес, а всех участников некредитного (а позже видимо и кредитного) финансового рынка, включая крупнейшие банки, страховые, НПФ и т.д. – но не чаще, чем дважды в год. Регламент внесения изменений в таксономию обозначен, к примеру, на слайде 12 этой презентации.
Не нужно пугать людей раньше времени. С 01.01.2018 ничего не будет. Все перенесли на «после 2018 г.» т.е. года полтора еще точно есть.
Поделитесь, откуда информация про после 2018?
Возможно, у вас есть более достоверный источник информации, чем ЦБ РФ, но на последней встрече в ЦБ, как и на всех предыдущих встречах, моментом перехода страховых, НПФ, ПУРЦБ, инвестиционных фондов на предоставление отчетности в формате XBRL обозначалась дата 01.01.2018.
Самые свежие материалы на сайте проекта – Презентация с заседания рабочей группы от 11.07.2017 (чуть более недели назад). План проекта вы можете найти на слайде 3, на нем отчетливо видна Подготовка отчетности в формате XBRL с начала 2018 года. В первых числах августа будет опубликован нормативный акт, регулирующий все вопросы подготовки отчетности в формате XBRL. Уверяю вас, в нем будут указаны те же самые сроки.
Срок перехода на XBRL с 01.01.2019 установлен только для несущественной части НФО, включающей в себя страховых брокеров, спецдепы, микрофинансовые организации, ломбарды и т.д., подробнее см. слайд 11 здесь.
Возможно, у вас есть более достоверный источник информации, чем ЦБ РФ, но на последней встрече в ЦБ, как и на всех предыдущих встречах, моментом перехода страховых, НПФ, ПУРЦБ, инвестиционных фондов на предоставление отчетности в формате XBRL обозначалась дата 01.01.2018.
Самые свежие материалы на сайте проекта – Презентация с заседания рабочей группы от 11.07.2017 (чуть более недели назад). План проекта вы можете найти на слайде 3, на нем отчетливо видна Подготовка отчетности в формате XBRL с начала 2018 года. В первых числах августа будет опубликован нормативный акт, регулирующий все вопросы подготовки отчетности в формате XBRL. Уверяю вас, в нем будут указаны те же самые сроки.
Срок перехода на XBRL с 01.01.2019 установлен только для несущественной части НФО, включающей в себя страховых брокеров, спецдепы, микрофинансовые организации, ломбарды и т.д., подробнее см. слайд 11 здесь.
Прошу прощения, скорее всего, вы правы (если ЦБ в последний момент опять все не перенесет). Я как сотрудник кредитной организации (банка) со своей колокольни смотрю :) Для банков отчетность XBRL будет после 2018 года.
Всё так, кредитные финансовые организации будут переводить на XBRL после НФО, не ранее 2019 года, а может и позже. Я как сотрудник страховой компании немного завидую вам в этом плане :)
Ну, нужно же ЦБ на ком-то «потренироваться» :) За НФО сказать не могу т.к. имею только базовые представления о текущем положении дел с ПО в данных организациях. Учитывая, что в данном случае речь идет о целом ряде организаций, деятельность которых сильно различается, подозреваю, что и в сфере применяемого ПО «зоопарк» тот еще.
Для банков переход на XBRL будет более простым, просто по причине достаточно ограниченного количества АБС (Автоматизированная Банковская Система) на Российском рынке.
Конечно, в первую очередь «под раздачу» попадут те банки, которые используют «самописные» АБС (in-house разработки) и гибридные решения типа back office «из коробки» + «самописная» АБС, ну или экзотические зарубежные варианты типа Olympic. Однако, иметь в России собственную in-house development АБС могут позволить себе только очень крупные кредитные организации, а у них, как правило, есть большой локальный штат собственных разработчиков, так что большой проблемой для них это не будет.
Остальная (большая) часть банков имеет АБС «из коробки» (Diasoft, ЦФТ, Афина и пр. список очень короткий). Тут все намного проще т.к. и поддержку XBRL они получат «из коробки» просто в рамках плановых обновлений АБС. Конечно, скорее всего, ряд АБС производителей не упустит возможности на этом немного «погреть руки», однако, большой проблемой для большинства банков это не будет.
Что касается технической реализации, был я в 2016 году на одной встрече по данной теме, там так же присутствовали (помимо ЦБ) еще и представители производителей ПО: Diasoft, 1C и ЦФТ. Причем, они все в один голос заявили, что не видят большой технической проблемы в переходе на XBRL отчетность. Так, представители 1С и Diasoft сказали, что просто добавят модуль конвертер текущей отчетности в XBRL без каких либо серьезных изменений в ядре систем. Учитывая то, что (сильно утрируя) основная «фишка» XBRL это введение множества дополнительных производных\промежуточных показателей, данный подход кажется абсолютно логичным и прозрачным. А вот ЦФТ говорили о глубокой интеграции логики XBRL в ядро,наверное, для того бы в очередной раз продать подороже .
В любом случае, пример с XBRL отчетностью, на мой взгляд, заставляет еще раз посмотреть в сторону и оценить плюсы именно проверенных отечественных решений «из коробки». Т.к. поддерживать собственные in-house разработки в таком быстро меняющемся мире становится все сложнее.
Для банков переход на XBRL будет более простым, просто по причине достаточно ограниченного количества АБС (Автоматизированная Банковская Система) на Российском рынке.
Конечно, в первую очередь «под раздачу» попадут те банки, которые используют «самописные» АБС (in-house разработки) и гибридные решения типа back office «из коробки» + «самописная» АБС, ну или экзотические зарубежные варианты типа Olympic. Однако, иметь в России собственную in-house development АБС могут позволить себе только очень крупные кредитные организации, а у них, как правило, есть большой локальный штат собственных разработчиков, так что большой проблемой для них это не будет.
Остальная (большая) часть банков имеет АБС «из коробки» (Diasoft, ЦФТ, Афина и пр. список очень короткий). Тут все намного проще т.к. и поддержку XBRL они получат «из коробки» просто в рамках плановых обновлений АБС. Конечно, скорее всего, ряд АБС производителей не упустит возможности на этом немного «погреть руки», однако, большой проблемой для большинства банков это не будет.
Что касается технической реализации, был я в 2016 году на одной встрече по данной теме, там так же присутствовали (помимо ЦБ) еще и представители производителей ПО: Diasoft, 1C и ЦФТ. Причем, они все в один голос заявили, что не видят большой технической проблемы в переходе на XBRL отчетность. Так, представители 1С и Diasoft сказали, что просто добавят модуль конвертер текущей отчетности в XBRL без каких либо серьезных изменений в ядре систем. Учитывая то, что (сильно утрируя) основная «фишка» XBRL это введение множества дополнительных производных\промежуточных показателей, данный подход кажется абсолютно логичным и прозрачным. А вот ЦФТ говорили о глубокой интеграции логики XBRL в ядро,
В любом случае, пример с XBRL отчетностью, на мой взгляд, заставляет еще раз посмотреть в сторону и оценить плюсы именно проверенных отечественных решений «из коробки». Т.к. поддерживать собственные in-house разработки в таком быстро меняющемся мире становится все сложнее.
Вы очень точно обозначили складывающуюся ситуацию. XBRL покажет, насколько качественные ИТ-решения и процессы имеет каждая из компаний. Для НФО, у которых нет крутых core-систем (далеко не все крупные НФО решаются на их внедрение) это будет видно особенно отчётливо.
Если сильно упрощать, то XBRL выдвигает новые требования к собираемым данным, значительно более широкие, чем было до сих пор; и у тех компании, где бизнес- и системный анализ, сбор и обработка данных отлажены как швейцарский хронометр, не составит большого труда удовлетворить эти требования, ведь завернуть готовые данные в xml нужного вида – технически несложная задачка. Остальным же предстоит колоссальный объём методологической и технической работы по созданию процессов подготовки данных для передачи в ЦБ. Про Excel и ручной ввод можно сразу забыть – счёт идёт на десятки тысяч значений ежемесячно.
Но самое печальное то, что ЦБ уже год кричит на всех углах про XBRL, про то, что всем давно пора бросать все и заниматься проектом, а то не никак успеть к концу года – но многие компании до сих не в курсе происходящего. Что ж, как говорится – держитесь там!
Если сильно упрощать, то XBRL выдвигает новые требования к собираемым данным, значительно более широкие, чем было до сих пор; и у тех компании, где бизнес- и системный анализ, сбор и обработка данных отлажены как швейцарский хронометр, не составит большого труда удовлетворить эти требования, ведь завернуть готовые данные в xml нужного вида – технически несложная задачка. Остальным же предстоит колоссальный объём методологической и технической работы по созданию процессов подготовки данных для передачи в ЦБ. Про Excel и ручной ввод можно сразу забыть – счёт идёт на десятки тысяч значений ежемесячно.
Но самое печальное то, что ЦБ уже год кричит на всех углах про XBRL, про то, что всем давно пора бросать все и заниматься проектом, а то не никак успеть к концу года – но многие компании до сих не в курсе происходящего. Что ж, как говорится – держитесь там!
Пресс-релиз Банка России:
Банк России опубликовал предварительную версию финальной таксономии бухгалтерской (финансовой), надзорной и статистической отчетности страховых организаций, негосударственных пенсионных фондов и профессиональных участников рынка ценных бумаг для их перехода на XBRL (eXtensible Business Reporting Language, расширяемый язык деловой отчетности).
В ближайшее время регулятор опубликует также программное обеспечение, которое позволит преобразовывать отчетные данные в формат XBRL с использованием этой таксономии и формировать в нем пакет отчетности. Таким образом, участники рынка смогут протестировать процесс формирования пакета отчетности.
Предварительная версия финальной таксономии разработана на основе модели данных и форм отчетности, публиковавшихся ранее. При этом ее структура и содержание максимально приближены к содержанию финальной таксономии, которую планируется опубликовать осенью 2017 года.
С 1 января 2018 года вводится обязательное использование формата XBRL для сбора и обработки отчетности страховых организаций, негосударственных пенсионных фондов, участников рынка ценных бумаг и управляющих компаний паевых и акционерных инвестиционных фондов.
31 июля 2017 года
Банк России опубликовал предварительную версию финальной таксономии бухгалтерской (финансовой), надзорной и статистической отчетности страховых организаций, негосударственных пенсионных фондов и профессиональных участников рынка ценных бумаг для их перехода на XBRL (eXtensible Business Reporting Language, расширяемый язык деловой отчетности).
В ближайшее время регулятор опубликует также программное обеспечение, которое позволит преобразовывать отчетные данные в формат XBRL с использованием этой таксономии и формировать в нем пакет отчетности. Таким образом, участники рынка смогут протестировать процесс формирования пакета отчетности.
Предварительная версия финальной таксономии разработана на основе модели данных и форм отчетности, публиковавшихся ранее. При этом ее структура и содержание максимально приближены к содержанию финальной таксономии, которую планируется опубликовать осенью 2017 года.
С 1 января 2018 года вводится обязательное использование формата XBRL для сбора и обработки отчетности страховых организаций, негосударственных пенсионных фондов, участников рынка ценных бумаг и управляющих компаний паевых и акционерных инвестиционных фондов.
31 июля 2017 года
XBRL — это просто формат. Сейчас страховые компании, например, через Пикософт формируют XTDD отчетность… Ну не будет Пикософта, будут другие инструменты меппинга на технологический формат. Таких тулов и в мире полно, и наши появятся. Вот некоммерческий проект с меппингом отчетности на XBRL есть — http://xbrl.org.ru. И это не считая бухгалтерских систем и АБС, где вендоры будут встраивать XBRL экспорт. У таких систем другая будет проблема — данные из разных систем надо свести в непротиворечивый и согласованный датасет и только потом этот датасет в XBRL сконвертировать, что не позволяет меппинг на 100% out-of-the-box реализовать.
В Пикософт данные заводятся по большей части вручную, хоть процесс их подготовки и может быть частично автоматизирован. Объем данных не очень большой, передаваемые через Пикософт формы бухгалтерия знает наизусть.
С XBRL ситуация сложнее – объем данных несоизмеримо больше и надо внимательно разбираться, как правильно привязать данные компании к концептам таксономии. Это внушительный объем методологической работы, который ложится либо на плечи бизнес-аналитиков компании, либо отдается на аутсорс.
Техническая сторона вопроса – конвертация массива отчетных данных в привязанный к таксономии XBRL-отчет – выглядит сравнительно проще.
Тем компаниям, у которых развернуты серьезные решения по бух.учету, будет немного проще, т.к. вендоры действительно могут добавить XBRL-модуль и обеспечить методологическую поддержку в рамках находящихся в системе данных – однако, это покрывает только часть концептов, и даже в этом случае останутся тысячи концептов, по которым необходим методологический анализ и какая-то техническая работа (скорее всего, согласованный с вендором способ ввода в модуль XBRL недостающих данных).
P.S. Указанный вами проект видимо не очень активен – выложена пара утилит (менее функциональный аналог Arelle и какой-то конвертер), перепост новостей.
С XBRL ситуация сложнее – объем данных несоизмеримо больше и надо внимательно разбираться, как правильно привязать данные компании к концептам таксономии. Это внушительный объем методологической работы, который ложится либо на плечи бизнес-аналитиков компании, либо отдается на аутсорс.
Техническая сторона вопроса – конвертация массива отчетных данных в привязанный к таксономии XBRL-отчет – выглядит сравнительно проще.
Тем компаниям, у которых развернуты серьезные решения по бух.учету, будет немного проще, т.к. вендоры действительно могут добавить XBRL-модуль и обеспечить методологическую поддержку в рамках находящихся в системе данных – однако, это покрывает только часть концептов, и даже в этом случае останутся тысячи концептов, по которым необходим методологический анализ и какая-то техническая работа (скорее всего, согласованный с вендором способ ввода в модуль XBRL недостающих данных).
P.S. Указанный вами проект видимо не очень активен – выложена пара утилит (менее функциональный аналог Arelle и какой-то конвертер), перепост новостей.
Не могу полностью согласиться. Модель данных в XBRL таксономии Банка России для некредитных финансовых организаций (НФО) за малым исключением полностью повторяет текущие требования надзора НФО и 100% соответствует требованиям Отраслевых стандартов бухгалтерского учета (ОСБУ). В том числе, в таксономии можно найти и визуализацию в виде, похожем на «классические» формы отчетности (Table Linkbase, Dimension Tables).
Таким образом: «С XBRL ситуация сложнее – объем данных несоизмеримо больше» — в текущей таксономии XBRL ЦБ это не так.
Про этот небольшой проект — не совсем так, Arelle — только инструмент просмотра, а тут один из тулов — это попытка реализации конвертера из Excel в XBRL, что в мире только за деньги.
Таким образом: «С XBRL ситуация сложнее – объем данных несоизмеримо больше» — в текущей таксономии XBRL ЦБ это не так.
Про этот небольшой проект — не совсем так, Arelle — только инструмент просмотра, а тут один из тулов — это попытка реализации конвертера из Excel в XBRL, что в мире только за деньги.
Разве сегмент НСО (надзорно-статистическая отчётность) таксономии НФО входит в состав передаваемых через Пикософт данных? (сам не знаю, поэтому спрашиваю) Даже если входит, Table linkbase я видел пока только в БФО сегменте.
НСО частично заполняется из счетов ЕПС и символов ОФР (но и там есть нюансы вроде разбивки счета/символа на несколько концептов по дополнительным аналитическим признакам. Кроме того есть концепты, факты по которым формируются только вручную (вроде Среднесписочной численности).
Так или иначе, основная моя мысль была в том, что прежде чем использовать XBRL-коробку (будь то новый модуль бухгалтерской учётной системы или АБС, либо отдельные решения вроде упомянутого вами конвертера), надо потратить немало времени на анализ соответствий между формами Пикософта/данными в системах компании и конвертами своей точки входа таксономии.
Да, под аналогом Arelle я имел в виду SXV XBRL Viewer.
НСО частично заполняется из счетов ЕПС и символов ОФР (но и там есть нюансы вроде разбивки счета/символа на несколько концептов по дополнительным аналитическим признакам. Кроме того есть концепты, факты по которым формируются только вручную (вроде Среднесписочной численности).
Так или иначе, основная моя мысль была в том, что прежде чем использовать XBRL-коробку (будь то новый модуль бухгалтерской учётной системы или АБС, либо отдельные решения вроде упомянутого вами конвертера), надо потратить немало времени на анализ соответствий между формами Пикософта/данными в системах компании и конвертами своей точки входа таксономии.
Да, под аналогом Arelle я имел в виду SXV XBRL Viewer.
Надзор субъектов страхового дела входит в Пикософт, в который заложена куча контрольных соотношений к этому надзору, не все из которых, кстати, сейчас заложены в таксономии XBRL для этого рынка.
Могу ошибаться, но надзорка в таксономии весьма субъективно связана с ЕПС и символами, так как технически (на уровне контрольных соотношений) она ближе к блоку ОСБУ (по таксономии опять же). Сейчас непонятно, как будут распределены между собой пакеты отчетности БФО и надзора в рамках XBRL. Следим за новостями с фронтов…
Показателей (фактов), формируемых действительно вручную, не так много — в основном это номера лицензий, уставные документы и тп.
Есть еще для профучастников блок в таксономии, который описывает показатели, которые надо сдавать при наступлении события (т.е. не регулярные). Пока вообще непонятно, как это технически будет происходить.
А в целом все верно. Вы правы. Это все боль для рынка даже в текущем варианте. А ранее в базовой и тн расширенной таксономиях были идеи еще и модель данных существенно детализировать. Это совсем бы всех подкосило, но вовремя отказались…
Отдельно про Table Linkbase — посмотрите, как оно в надзорном блоке. Есть мысль, что эту часть таксономии можно утилизировать для автоматизации.
Могу ошибаться, но надзорка в таксономии весьма субъективно связана с ЕПС и символами, так как технически (на уровне контрольных соотношений) она ближе к блоку ОСБУ (по таксономии опять же). Сейчас непонятно, как будут распределены между собой пакеты отчетности БФО и надзора в рамках XBRL. Следим за новостями с фронтов…
Показателей (фактов), формируемых действительно вручную, не так много — в основном это номера лицензий, уставные документы и тп.
Есть еще для профучастников блок в таксономии, который описывает показатели, которые надо сдавать при наступлении события (т.е. не регулярные). Пока вообще непонятно, как это технически будет происходить.
А в целом все верно. Вы правы. Это все боль для рынка даже в текущем варианте. А ранее в базовой и тн расширенной таксономиях были идеи еще и модель данных существенно детализировать. Это совсем бы всех подкосило, но вовремя отказались…
Отдельно про Table Linkbase — посмотрите, как оно в надзорном блоке. Есть мысль, что эту часть таксономии можно утилизировать для автоматизации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XBRL: Просто о сложном − Глава 1. Введение