1. Язык XBRL
1.1) Истоки Применение информатики в бизнесе и бухгалтерском учете стало одним из последних достижений в языке XBRL. Известны ошибки и потеря времени, вызванные повторным набором финансовых отчетов, выпущенных различными организациями, либо для их последующего анализа, либо для хранения информации. По этой причине в 1998 году Чарльз Хоффман разработал язык XBRL, начиная с его работы с языком XML. Аббревиатура XBRL является аббревиатурой от eXtensible Business Reporting Language (Расширяемый язык бизнес-отчетности). В основе этой инициативы лежала не что иное, как стандартизация формата, в котором финансовая информация распространяется между различными поставщиками и потребителями.
Стандарт администрируется международным некоммерческим консорциумом (XBRL International Incorporated), состоящим примерно из 450 организаций, включая регулирующие органы, правительственные агентства, консультанты и разработчиков программного обеспечения.
XBRL направлен на стандартизацию формата деловой и финансовой информации, циркулирующей в цифровом виде.
Для этого он основан на определении таксономий, наборе метаданных, которые описывают данные, которые должны быть сообщены, формат и структуру, которые они имеют, а также отношения между упомянутыми данными.
Технически эти таксономии представляют собой схемы XML, которые должны соответствовать стандартам, установленным спецификацией XBRL, опубликованной XBRL International, версия в настоящее время действует.
1.1 этой спецификации
С другой стороны, данные, которые мы хотим сообщить, то есть экономические факты об организации и конкретный период времени, представлены тем, что мы называем отчетами XBRL (экземпляры на английском языке), которые технически представляют собой файлы XML, которые будут ссылаться на таксономию, схему XML, на котором они основаны.
1.2 Как работает XBRL
XBRL - это надстройка для компьютерного программирования, которая помечает каждый сегмент автоматизированной бизнес-информации идентификационным кодом или маркером. В большинстве случаев бухгалтерское программное обеспечение вставляет этикетки автоматически. Если в вашем плане счетов отсутствует функция XBRL, вы можете добавить теги, используя бесплатную дополнительную программу или настраиваемые программные инструменты тегирования.
Маркеры идентификации остаются с данными при их перемещении или изменении. Таким образом, независимо от того, как вы (или, точнее, ваше прикладное программное обеспечение, такое как электронная таблица или текстовый процессор) форматируете или изменяете информацию, маркеры остаются прикрепленными к ней. Таким образом, число, определенное как представление, например, прибыли в долларах США, всегда будет распознаваться таким образом. Типичные ярлыки включают финансовую идентификацию, такую как активы, текущие активы и дебиторская задолженность.
Если программа XBRL не содержит идентификационных маркеров, отвечающих потребностям вашего бизнеса, вы можете легко создать свои собственные маркеры и добавить их, поскольку программа полностью настраивается.
В соответствии с языком бухгалтерского учета набор элементов или меток с автономными и собственными правилами, которые должны выполняться во время обработки данных при подготовке отчета, называется словарем данных, который был построен и уже был у него есть то, что технически называется Таксономией, которая должна быть принята повсеместно.
2. Оцифровка процессов обмена информацией: процессы закупок и выставления счетов.
Теперь, несомненно, язык XBRL позволяет упростить обмен информацией и последующий анализ финансовой отчетности, помогая менеджерам, инвесторам, аналитикам и т. Д. этого не будет видно в утомительной задаче повторного набора, преобразования письменного документа в двоичную информацию, различных бухгалтерских отчетов.
Но что происходит на оперативном уровне? То есть, какой прогресс произошел на уровне обмена основной информацией, выставления счетов, покупок, выдачи платежей и т. Д.
Мы считаем, что на повседневном рабочем уровне это точно так же, как до принятия языка XBRL для отчетности и бухгалтерских отчетов. Во всем процессе административного учета используется двойная запись, а если нет, то тройная или учетная запись тех же записей.
В процессах закупок и выставления счетов административные должностные лица компаний-поставщиков и закупающих компаний вводят одно и то же: некоторые проверяют товары и регистрируют движения на счетах дебиторов, другие регистрируют ввод товаров и движения в В случае счетов кредиторов возникает феноменальное дублирование задач, которое дорого обходится руководству связанных компаний.
Давайте посмотрим на пример обычного процесса покупки, а именно:
а) Определение потребности в покупках: предположим, что мы компьютеризированы, и система сообщает о товарах, которые мы должны добавить в наш склад. Затем мы перезваниваем, отправляем электронное письмо или устанавливаем механизм связи с нашими поставщиками для размещения заказа через Заказ на поставку.
б) Подготовка счета-фактуры и / или денежного перевода: при предположении, что цена и условия оплаты уже приняты, должностное лицо поставщика должно выписать перевод и / или счет-фактуру, выбрав заказанные товары и назначив им цену в соответствии со списком дадаистов.
Позже система бухгалтерского учета сделает записи стиля.
c) Регистрация поступления товаров и полученного счета-фактуры: точно так же, но в противоположном направлении, вместо низкого запаса, высокого и вместо должника, кредитора, какого-либо административного должностного лица вы должны повторно ввести элемент за элементом, количество за количеством полученный счет-фактура покупки.
Как мы видим ранее, как и в финансовых отчетах, которые нужно было вводить снова, на административном уровне, эта ситуация повторяется на повседневной основе тысячи раз, коды позиций, количества, цены, повторно вводятся в продавцах и покупателях, максимум акции, которые точно соответствуют вывозу запасов.
Казалось бы, старый принцип бухгалтерского учета «двойной записи» был неверно истолкован как «введите все дважды».
Возникает вопрос, а нельзя ли сформулировать такой механизм входа-выхода товаров, который не предполагал бы повторной оцифровки и дублирования задач?
Большая проблема: коды артикулов.
Все это безмерное дублирование задач существует потому, что коды продавцов и покупателей несовместимы, то есть один и тот же товар, он называется по-разному у поставщика, а у покупателя по-другому, если не по-разному в разных отраслях. покупателя. Это как если бы человек каждый раз, путешествуя, менял свое имя в каждой стране, которую он посещал, поэтому он должен знать, где он должен узнать свое имя, это звучит смешно, но это то, что мы делаем на административном уровне.
Хуан - это Хуан везде ……
Если бы мы сохранили имена поставщиков, то есть их коды, если бы не было более чем широко распространенного обычая перекодировать каждый товар при каждой покупке, просто с помощью плоского файла с данными о закупках, системы каждой компании могли бы быть загружены из тот же источник.
Повторный ввод данных существует, потому что каждый раз, когда товар приобретается в компании, размещается его внутренний код, и движение на склад должен регистрироваться с помощью указанного кода. Если бы коды были одинаковыми или существовал переводчик, системы могли бы вводить «цифровые счета-фактуры», просто читая файлы, присланные провайдером.
Операция, если бы процесс был оцифрован, была бы такой:
Хотя рабочая схема похожа на обычную, большая разница заключается в отсутствии перекодирования статей, и поэтому вход в системы осуществляется непосредственно путем «захвата» данных в цифровой форме.
В конечном итоге, если продавцы согласовывают типы полей, форматы и коды переноса статей, ввод текста во время покупки полностью исключается. Вышеупомянутое представляет собой очень важный шаг вперед, когда дело доходит до повышения эффективности административных процессов, экономятся тысячи часов набора текста, выверка счетов может производиться онлайн и т. Д.
То же самое, что XBRL подразумевает для консолидированной информации, может быть применено к базовой бухгалтерской информации.
Посмотрим, как будет работать процесс:
1) Отправка прайс-листа в цифровом файле или на веб-страницах:
Поставщики отправят цифровой прайс-лист и формат кода товара или создадут веб-страницу для размещения заказов на поставку.
2) Подача электронных счетов:
После того, как заказ принят и как только товар будет отправлен, онлайн-счет отправляется в электронном виде с теми же данными, что и общий счет, который сопровождает товар.
3) Сбор информации:
Как только товар прибывает, он проверяется, и электронный счет контролируется вместе с отправленным счетом.
После выполнения этого процесса компьютерные системы, которые «понимают» счета-фактуры поставщиков, Хуан - это Хуан, а не Диего или Альберто, включают счета-фактуры в систему складских запасов и создают бухгалтерскую проводку.
Как видите, единственный раз, когда приходилось вводить коды и вводить счета, было создание цифровых заказов на покупку или веб-сайта.
Наконец, с точки зрения сборного офиса, было бы очень легко контролировать, чтобы суммы налогов, выставляемых одной стороной, в точности соответствовали вычету другой.
Произошел качественный скачок?: включить интеллект
Теперь, хотя верно то, что предыдущее предложение предполагает дополнительный прогресс в административных процессах, на самом деле это применение тех же концепций стандартизации форматов и оцифровки, которые применяются в XBRL.
Это экономит время работы, исключает повторные аппликатуры, но на самом деле мы думаем, что это не означает больших изменений в процессах, они просто становятся более эффективными.
Поэтому возникает вопрос, когда же будет сделан качественный скачок?
Мы считаем, что большие изменения произойдут, когда вы воспользуетесь огромным потенциалом обработки и хранения данных в существующих системах. При нынешних скоростях вполне возможно думать, что компьютерные системы выполняют автономную деятельность, которая сегодня предназначена исключительно для различных должностных лиц организации.
То есть, если системы запрограммированы поведенческими правилами и подключены к Интернету, учитывая возможность диалога, который существует между ними, вполне возможно, что запрос цены от поставщика, даже покупка до пределов которые фиксируются, могут выполняться автономно.
После того, как коды товаров стандартизированы или переведены, система, достигнув точки пополнения, может идеально взаимодействовать с компаниями-поставщиками через сеть, «диалог» между системами и заказы заказов.
В свою очередь, после того, как они были сформулированы и доставлены, системы могут интегрировать отправляемую им платежную информацию в свои системы бухгалтерского учета.
Очевидно, что необходимо установить контроль приема товаров, как мы упоминали ранее, чтобы товары, которые не контролировались должным образом, не включались в системы.
Хотя взаимосвязь систем, автономный диалог и запрограммированная реакция кажется слишком футуристической концепцией, это именно то, что делается в медицинской науке путем лечения программируемого кардиостимулятора или кардиофибриллятора. Другими словами, тысячи людей в мире живут благодаря тому, что существуют системы, которые регистрируют, подключаются и действуют абсолютно в одиночку.
Поэтому мы считаем, что в бухгалтерской науке, как и в медицине, можно сделать большой скачок, будь то планирование закупок, денежные переводы или коммерческая сфера. Системы должны проводить переписи, сравнивать с их правилами поведения и действовать ……
Искусственный интеллект, применяемый к бухгалтерским процессам, является определяющим, как определено Элейн Рич и Кевином Нийгтом (1):
«Искусственный интеллект (ИИ) изучает, как создавать машины выполнять задачи, которые на данный момент выполняются Человеческими Существами "
В конечном счете, мы должны иметь возможность подражать человеческому поведению с помощью правил, априори разработанных применительно к системам бухгалтерского учета, например:
Правило:
Короче говоря, если у меня нет запасов, я нахожусь в периоде года, когда мне нужно соответствовать минимальному запасу, и я могу заплатить за него, а затем: я размещаю заказ. Эти концепции называются экспертными системами:
Варианты этого типа проблем можно найти, комбинируя несколько логических правил, или они также решаются с помощью так называемых систем на основе случаев, которые применяют прошлый опыт для решения текущего случая.
Таким образом, мы делаем вывод, что, как и в случае с атлетом тройного прыжка, в 80-х годах мы поддержали первую ногу с появлением ПК, в 90-х годах посредством обмена бухгалтерской информацией (XBRL) мы поддержали вторую, но Мы сделаем большой шаг вперед, когда сможем делегировать интеллектуальным системам задачи, которые до сегодняшнего дня мы полагаемся только на наших собственных административных чиновников разной иерархии…
