0

    Технологии и Бизнес часто вызывают для пересмотра новых таксономий XBRL. Вот некоторые из наиболее распространенных ошибок, которые мы находим, и что можно сделать, чтобы их избежать.

    Ошибки формулы XBRL

    Формула XBRL используется для определения бизнес-правил, которые имеют решающее значение для поддержания ценности собранных данных. Удивительно, что 16 из 100 протестированных таксономий были выпущены по крайней мере с одним бизнес-правилом, которое не могло быть выполнено в совместимом со спецификацией процессоре XBRL. Наиболее вероятными ошибками были попытки сравнить текст с числами и случаи, когда формула могла вызвать ошибку «деление на ноль».

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

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

    Ошибки упаковки

    Правильная упаковка таксономии означает, что настройка части программного обеспечения XBRL может быть такой же простой, как и установка пакета. Хотя спецификация упаковки XBRL, возможно, является самым простым документом в наборе XBRL, только 75% таксономий, которые рассматривались, были правильно упакованы с типичными ошибками, такими как опечатки в адресах точек входа, необходимые папки отсутствуют или не упакованы вообще.

    Подобно формуле, они обычно сводятся к человеческой ошибке. Тем не менее, в этом случае проблема заключается не в затруднении, а в том, что он предполагает сложную природу работы с длинными веб-адресами и необходимость точной архивации файлов и папок. Опять же, сценарии или другая автоматизация процесса упаковки является решением. Чтобы помочь сообществу с упаковкой (и так как спецификация началась в Технологии и Бизнес), мы выпустили генератор пакетов для всех.

    Непоследовательное управление версиями

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

    Хотя это и не является ошибкой как таковой, это делает отслеживание версий проблемой для файлов. Дважды проверять, какую версию использовать, исторически является наиболее распространенным запросом поддержки Технологии и Бизнес, в результате чего мы публикуем средство выбора мандатов, которое податели могут использовать для ответа на этот вопрос. Подобно ошибкам спецификации, несовместимое управление версиями приводит к ненужным дополнительным затратам во всей экосистеме регистрирующей программы.

    Три главных совета для того, чтобы заставить работу версий работать с пользователями таксономии:

    • Выберите схему управления версиями и придерживайтесь ее! Люди могут изучать схему и работать с ней, они могут потеряться при изменении схемы.
    • Всегда применяйте новый номер версии к каждому выпуску. Даже если это исправление или таксономии выпущены в быстрой последовательности, никогда не должно быть никакой двусмысленности относительно точного содержания конкретной версии.
    • Предпочитаю последовательные числа по датам. Отличной схемой управления версиями по умолчанию является схема с 3 числами [основной выпуск]. [Дополнительный выпуск]. [Номер исправления]. В отличие от схем на основе дат, они являются гибкими, простыми для понимания и одинаково действительными, когда даты изменяются или их актуальность забывается.

    Почему это важно?

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

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

    По-другому!

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

    Приходите и убедитесь сами. Технологии и Бизнес проводит консультации по созданию таксономии, где организации могут получить опыт создания 100% безошибочных таксономий с использованием собственных требований к данным.

    ПОМОЖЕМ ВНЕДРИТЬ ОТЧЕТНОСТЬ В ФОРМАТЕ XBRL ЗА 8 ЧАСОВ

    кнопка получить предложение

    Настройка 1С 8.3 с нуля

    БЕСПЕРЕБОЙНАЯ РАБОТА БУХГАЛТЕРСКИХ ПРОГРАММ

    И СВОЕВРЕМЕННОЕ ОБНОВЛЕНИЕ?

    кнопка получить предложение

    Как вести бухгалтерию ООО без помощи посторонних?

    Previous article

    Расчет отпускных: примеры

    Next article

    You may also like

    Comments

    Leave a reply

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    More in XBRL