Мэппинг данных что это

Маппинг данных из реляционной БД

Иногда возникают ситуации, когда решение задачи выборки данных из реляционной БД не укладывается в возможности используемой в проекте ОРМ, например, либо из-за недостаточной скорости работы самой ОРМ, либо не совсем оптимальных SQL запросов генерируемых ею. В таком случае обычно приходится писать запросы вручную.

Проблема в том, что данные из БД (в т.ч. в ответ на JOIN запрос) возвращаются в виде “плоского” двухмерного массива никак не отражающего сложную “древовидную” структуру данных приложения. Работать с таким массивом дальше крайне неудобно, поэтому требуется более-менее универсальное решение, позволяющее привести этот массив в более подходящий вид по заданному шаблону.

Решение было найдено, удобное и достаточно быстрое.

На сколько быстрое

Для оценки скорости работы библиотеки я собрал небольшой испытательный стенд на котором скорость работы моей библиотеки сравнивается со скоростью работы Eloquent. Для замеров использовался пакет phpbench.

Для того чтобы развернуть стенд у себя:

Здесь я использовал инструмент описанный в моей предыдущей статье.

Затем в меню выбираем: 1 Develop, затем: 1 Build, затем 2 Deploy and Up;
Затем запускаем тесты 5. Run tests

В базе 3000 книг. Результаты получились следующие:

benchEloquent — вытаскивает все книги с авторами с использованием Eloquent
benchEloquentId — вытаскивает определенную книгу с авторами с использованием Eloquent (10 раз)

benchProc — вытаскивает все книги с авторами с использованием библиотеки
benchProcId — вытаскивает определенную книгу с авторами с использованием библиотеки (10 раз)

Возможно приведенные тесты недостаточно репрезентативны, но разница заметна, как по времени выполнения, так и по расходованию памяти.

Как это работает

Далее, для примера (крайне простого), представим, что у нас имеется БД книг и авторов со следующей структурой.

Задача — вытащить все книги с их авторами.

Запрос будет выглядеть как-то так:

В ответ мы получим примерно такой массив данных.

Для этого немного изменим наш запрос:

Здесь мы в секции SELECT задали алиасы: для полей с данными о книгах алиасы с префиксом ‘book_’, а для полей с информацией об авторах с префиксом ‘author’.

Далее преобразуем ответ БД

$rows — ответ БД в виде массива объектов /stdClass()
$config — ассоциативный массив отражающий структуру данных итогового массива

Источник

Организация памяти процесса

Управление памятью – центральный аспект в работе операционных систем. Он оказывает основополагающее влияние на сферу программирования и системного администрирования. В нескольких последующих постах я коснусь вопросов, связанных с работой памяти. Упор будет сделан на практические аспекты, однако и детали внутреннего устройства игнорировать не будем. Рассматриваемые концепции являются достаточно общими, но проиллюстрированы в основном на примере Linux и Windows, выполняющихся на x86-32 компьютере. Первый пост описывает организацию памяти пользовательских процессов.

Каждый процесс в многозадачной ОС выполняется в собственной “песочнице”. Эта песочница представляет собой виртуальное адресное пространство, которое в 32-битном защищенном режиме всегда имеет размер равный 4 гигабайтам. Соответствие между виртуальным пространством и физической памятью описывается с помощью таблицы страниц (page table). Ядро создает и заполняет таблицы, а процессор обращается к ним при необходимости осуществить трансляцию адреса. Каждый процесс работает со своим набором таблиц. Есть один важный момент — концепция виртуальной адресации распространяется на все выполняемое ПО, включая и само ядро. По этой причине для него резервируется часть виртуального адресного пространства (т.н. kernel space).

Это конечно не значит, что ядро занимает все это пространство, просто данный диапазон адресов может быть использован для мэппирования любой части физического адресного пространства по выбору ядра. Страницы памяти, соответствующие kernel space, помечены в таблицах страниц как доступные исключительно для привилегированного кода (кольцо 2 или более привилегированное). При попытке обращения к этим страницам из user mode кода генерируется page fault. В случае с Linux, kernel space всегда присутствует в памяти процесса, и разные процессы мэппируют kernel space в одну и ту же область физической памяти. Таким образом, код и данные ядра всегда доступны при необходимости обработать прерывание или системный вызов. В противоположность, оперативная память, замэппированная в user mode space, меняется при каждом переключении контекста.

Синим цветом на рисунке отмечены области виртуального адресного пространства, которым в соответствие поставлены участки физической памяти; белым цветом — еще не использованные области. Как видно, Firefox использовал большую часть своего виртуального адресного пространства. Все мы знаем о легендарной прожорливости этой программы в отношении оперативной памяти. Синие полосы на рисунке — это сегменты памяти программы, такие как куча (heap), стек и так далее. Обратите внимание, что в данном случае под сегментами мы подразумеваем просто непрерывные адресные диапазоны. Это не те сегменты, о которых мы говорим при описании сегментации в Intel процессорах. Так или иначе, вот стандартная схема организации памяти процесса в Linux:

Давным давно, когда компьютерная техника находилась в совсем еще младенческом возрасте, начальные виртуальные адреса сегментов были совершенно одинаковыми почти для всех процессов, выполняемых машиной. Из-за этого значительно упрощалось удаленное эксплуатирование уязвимостей. Эксплойту часто необходимо обращаться к памяти по абсолютным адресам, например по некоторому адресу в стеке, по адресу библиотечной функции, и тому подобное. Хакер, рассчитывающий осуществить удаленную атаку, должен выбирать адреса для обращения в слепую в расчете на то, что размещение сегментов программы в памяти на разных машинах будет идентичным. И когда оно действительно идентичное, случается, что людей хакают. По этой причине, приобрел популярность механизм рандомизации расположения сегментов в адресном пространстве процесса. Linux рандомизирует расположение стека, сегмента для memory mapping, и кучи – их стартовый адрес вычисляется путем добавления смещения. К сожалению, 32-битное пространство не очень-то большое, и эффективность рандомизации в известной степени нивелируется.

В верхней части user mode space расположен стековый сегмент. Большинство языков программирования используют его для хранения локальных переменных и аргументов, переданных в функцию. Вызов функции или метода приводит к помещению в стек т.н. стекового фрейма. Когда функция возвращает управление, стековый фрейм уничтожается. Стек устроен достаточно просто — данные обрабатываются в соответствии с принципом «последним пришёл — первым обслужен» (LIFO). По этой причине, для отслеживания содержания стека не нужно сложных управляющих структур – достаточно всего лишь указателя на верхушку стека. Добавление данных в стек и их удаление – быстрая и четко определенная операция. Более того, многократное использование одних и тех же областей стекового сегмента приводит к тому, что они, как правило, находятся в кеше процессора, что еще более ускоряет доступ. Каждый тред в рамках процесса работает с собственным стеком.

Возможна ситуация, когда пространство, отведенное под стековый сегмент, не может вместить в себя добавляемые данные. В результате, будет сгенерирован page fault, который в Linux обрабатывается функцией expand_stack(). Она, в свою очередь, вызовет другую функцию — acct_stack_growth(), которая отвечает за проверку возможности увеличить стековый сегмент. Если размер стекового сегмента меньше значения константы RLIMIT_STACK (обычно 8 МБ), то он наращивается, и программа продолжает выполняться как ни в чем не бывало. Это стандартный механизм, посредством которого размер стекового сегмента увеличивается в соответствии с потребностями. Однако, если достигнут максимально разрещённый размер стекового сегмента, то происходит переполнение стека (stack overflow), и программе посылается сигнал Segmentation Fault. Стековый сегмент может увеличиваться при необходимости, но никогда не уменьшается, даже если сама стековая структура, содержащаяся в нем, становиться меньше. Подобно федеральному бюджету, стековый сегмент может только расти.

Динамическое наращивание стека – единственная ситуация, когда обращение к «немэппированной» области памяти, может быть расценено как валидная операция. Любое другое обращение приводит к генерации page fault, за которым следует Segmentation Fault. Некоторые используемые области помечены как read-only, и обращение к ним также приводит к Segmentation Fault.

Под стеком располагается сегмент для memory mapping. Ядро использует этот сегмент для мэппирования (отображания в память) содержимого файлов. Любое приложение может воспользоваться данным функционалом посредством системного вызовома mmap() (ссылка на описание реализации вызова mmap) или CreateFileMapping() / MapViewOfFile() в Windows. Отображение файлов в память – удобный и высокопроизводительный метод файлового ввода / вывода, и он используется, например, для загрузки динамических библиотек. Существует возможность осуществить анонимное отображение в память (anonymous memory mapping), в результате чего получим область, в которую не отображен никакой файл, и которая вместо этого используется для размещения разного рода данных, с которыми работает программа. Если в Linux запросить выделение большого блока памяти с помощью malloc(), то вместо того, чтобы выделить память в куче, стандартная библиотека C задействует механизм анонимного отображения. Слово «большой», в данном случае, означает величину в байтах большую, чем значение константы MMAP_THRESHOLD. По умолчанию, это величина равна 128 кБ, и может контролироваться через вызов mallopt().

Кстати о куче. Она идет следующей в нашем описании адресного пространства процесса. Подобно стеку, куча используется для выделения памяти во время выполнения программы. В отличие от стека, память, выделенная в куче, сохранится после того, как функция, вызвавшая выделение этой памяти, завершится. Большинство языков предоставляют средства управления памятью в куче. Таким образом, ядро и среда выполнения языка совместно осуществляют динамическое выделение дополнительной памяти. В языке C, интерфейсом для работы с кучей является семейство функций malloc(), в то время как в языках с поддержкой garbage collection, вроде C#, основной интерфейс – это оператор new.

Если текущий размер кучи позволяет выделить запрошенный объем памяти, то выделение может быть осуществлено средствами одной лишь среды выполнения, без привлечения ядра. В противном случае, функция malloc() задействует системный вызов brk() для необходимого увеличения кучи (ссылка на описание реализации вызова brk). Управление памятью в куче – нетривиальная задача, для решения которой используются сложные алгоритмы. Данные алгоритмы стремятся достичь высокой скорости и эффективности в условиях непредсказуемых и хаотичных пэттернов выделения памяти в наших программах. Время, затрачиваемое на каждый запрос по выделению памяти в куче, может разительно отличаться. Для решения данной проблемы, системы реального времени используют специализированные аллокаторы памяти. Куча также подвержена фрагментированию, что, к примеру, изображено на рисунке:

Наконец, мы добрались до сегментов, расположенных в нижней части адресного пространства процесса: BSS, сегмент данных (data segment) и сегмент кода (text segment). BSS и data сегмент хранят данные, соответствующий static переменным в исходном коде на C. Разница в том, что в BSS хранятся данные, соответствующие неинициализированным переменным, чьи значения явно не указаны в исходном коде (в действительности, там хранятся объекты, при создании которых в декларации переменной либо явно указано нулевое значение, либо значение изначально не указано, и в линкуемых файлах нет таких же common символов, с ненулевым значением. – прим. перевод.). Для сегмента BSS используется анонимное отображение в память, т.е. никакой файл в этот сегмент не мэппируется. Если в исходном файле на C использовать int cntActiveUsers, то место под соответствующий объект будет выделено в BSS.

В отличии от BSS, data cегмент хранит объекты, которым в исходном коде соответствуют декларации static переменных, инициализированных ненулевым значением. Этот сегмент памяти не является анонимным — в него мэппируется часть образа программы. Таким образом, если мы используем static int cntWorkerBees = 10, то место под соответствующий объект будет выделено в data сегменте, и оно будет хранить значение 10. Хотя в data сегмент отображается файл, это т.н. «приватный мэппинг» (private memory mapping). Это значит, что изменения данных в этом сегменте не повлияют на содержание соответствующего файла. Так и должно быть, иначе присвоения значений глобальным переменным привели бы к изменению содержания файла, хранящегося на диске. В данном случае это совсем не нужно!

Мы можем посмотреть, как используются области памяти процесса, прочитав содержимое файла /proc/pid_of_process/maps. Обратите внимание, что содержимое самого сегмента может состоять из различных областей. Например, каждой мэппируемой в memory mapping сегмент динамической библиотеке отводится своя область, и в ней можно выделить области для BSS и data сегментов библиотеки. В следующем посте поясним, что конкретно подразумевается под словом “область”. Учтите, что иногда люди говорят “data сегмент”, подразумевая под этим data + BSS + heap.

Можно использовать утилиты nm и objdump для просмотра содержимого бинарных исполняемых образов: символов, их адресов, сегментов и т.д. Наконец, то, что описано в этом посте – это так называемая “гибкая” организация памяти процесса (flexible memory layout), которая вот уже несколько лет используется в Linux по умолчанию. Данная схема предполагает, что у нас определено значение константы RLIMIT_STACK. Когда это не так, Linux использует т.н. классическую организации, которая изображена на рисунке:

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

Источник

Учет по МСФО в программном продукте: трансляция или трансформация?

В связи с принятием Закона № 208-ФЗ «О консолидированной финансовой отчетности» увеличивается нагрузка на финансовые службы российских организаций и, как следствие, растет интерес менеджмента к вопросу организации автоматизированной подготовки отчетности по МСФО.

Предпосылки автоматизации учета по МСФО

В последние годы многие российские компании и группы компаний, не дожидаясь законодательного признания МСФО, в добровольном порядке начали готовить отчетность по международным стандартам согласно запросам инвесторов, кредиторов, иностранных партнеров и других заинтересованных пользователей.

Согласно Закону № 208-ФЗ консолидированная финансовая отчетность в соответствии с МСФО должна публиковаться кредитными организациями, страховыми организациями, иными организациями, ценные бумаги которых допущены к обращению на торгах фондовых бирж и (или) иных организаторов торговли на рынке ценных бумаг.

Такая отчетность должна представляться организациями (за исключением тех, для которых установлены особые сроки) начиная с отчетности за 2012 г.

Теперь, когда отчетность по МСФО становится обязательной для большого числа российских компаний, возникает необходимость продумать наиболее оптимальный способ подготовки такой отчетности. Концептуально на практике существует два классических варианта:

• составлять отчетность по МСФО вручную путем трансформации данных российского бухгалтерского учета (далее БУ);

• автоматизировать процесс подготовки отчетности по МСФО (возможно полностью независимое от бухгалтерского учета ведение учета по МСФО либо получение части данных по МСФО на основе данных БУ, частично ведя независимый учет по отдельным участкам).

Как известно, самый простой, быстрый и дешевый способ, вместе с тем обладающий рядом объективных недостатков, — это трансформация в электронных таблицах и базах данных (например, MS Excel). Более сложный, но вместе с тем более точный и качественный — это использование автоматизированных средств подготовки отчетности по МСФО.

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

• Трансформационные ведомости (если автоматизируется трансформация).

• Оборотно-сальдовая ведомость МСФО по каждой компании в группе, сформированная по плану счетов МСФО, и типовые расшифровки по каждому счету (анализ счета, карточка счета, оборотно-сальдовая ведомость по счету и др.).

• Индивидуальная отчетность по МСФО по каждой компании в группе (отчет о финансовой позиции, отчет о совокупном доходе, отчет о движении денежных средств, отчет об изменениях капитала и расшифровки к ним в виде дополнительных отчетов).

• Консолидированная отчетность по МСФО (для группы в целом/для отдельных подгрупп в группе).

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

Метод трансляции данных

Данный метод предполагает создание подсистемы МСФО в программном продукте, где ведется бухгалтерский учет компании.

Подсистема МСФО — подсистема ведения учета и формирования отчетности в соответствии с Международными стандартами финансовой отчетности в составе автоматизированной системы ведения бухгалтерского учета.

Таким образом, подсистема МСФО представляет собой функционал по автоматизированному ведению учета по МСФО в учетной системе компании, выбранной для целей ведения бухгалтерского учета.

1. Конвертация (трансляция) проводок БУ по правилам мэппинга.

Мэппинг (карта соответствия, правила соответствия) — правила соответствия между данными БУ и МСФО, задаваемые в подсистеме МСФО.

Конвертация, трансляция данных — автоматический перенос данных из БУ на план счетов МСФО в соответствии с правилами мэппинга.

2. Независимое ведение учета по МСФО по участкам, которые не подлежат конвертации из БУ в силу различных подходов к учету в БУ и МСФО (например, основные средства, лизинг, договоры подряда, отложенные налоги, обесценение финансовых активов, формирование себестоимости и др.), при помощи специально разработанного функционала (документы, обработки) с возможностью анализа движений БУ за период.

3. Операции, которые не конвертируются из БУ и для которых нецелесообразно реализовывать специальный функционал, подлежат отражению ручными операциями (бухсправками по МСФО).

При этом конвертация выполняется в полностью автоматическом режиме, без участия специалистов по МСФО, и позволяет получить 70–80 % от общего объема проводок по МСФО. Параллельное (независимое от бухгалтерского учета) ведение учета по отдельным участкам и формирование ручных операций требует участия специалистов со знанием МСФО.

Имея в системе ведения бухгалтерского учета еще и учет по МСФО, не составляет труда организовать автоматическое формирование отчетности по МСФО. При этом часто индивидуальная отчетность может и не требоваться, в силу того что компания входит в группу, по которой составляется консолидированная отчетность по МСФО.

Схема подготовки консолидированной отчетности при ведении учета по МСФО методом трансляции данных на уровне отдельных компаний может выглядеть, как показано на схеме 1.

Схема 1. Подготовка консолидированной отчетности при ведении учета по МСФО методом трансляции данных

При этом сама консолидация может выполняться как в MS Excel (это оправданно, когда компаний в периметре консолидации не много, расчеты между ними несложные и выверенные на уровне бухгалтерского учета), так и в отдельном программном продукте, предназначенном для консолидации данных (например, «1С:Консолидация»).

Также функционал по автоматизированной консолидации данных можно организовать и в рамках подсистемы МСФО материнской компании. Тогда архитектура процесса будет выглядеть, как показано на схеме 2.

Схема 2. Подготовка консолидированной отчетности в программном продукте материнской компании

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

Функционал по автоматизированной консолидации данных предполагает:

1) определение периметра внутригрупповых контрагентов и перечня неконтролирующих акционеров;

2) выполнение сверки внутригрупповых расчетов;

3) формирование сводных данных по периметру консолидации с последующим исключением внутригрупповых остатков и оборотов;

4) расчет и исключение нереализованной прибыли по внутригрупповым продажам;

5) регистрацию и хранение информации о справедливой стоимости чистых активов дочерних компаний;

6) расчет и признание гудвилла по дочерним компаниям;

7) расчет и признание доходов и расходов от участия в ассоциированных компаниях и совместных предприятиях, а также стоимости инвестиций в эти компании и др.

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

1. План счетов (далее ПС) МСФО.

2. Карта соответствия (мэппинг) между ПС МСФО и ПС БУ.

3. Нормативно-справочная информация, используемая для целей МСФО (справочники, классификаторы, перечисления и др.).

4. Методики ведения учета по МСФО по отдельным участкам.

5. Альбом отчетных форм (с методикой формирования показателей).

6. Карта функционального покрытия.

Карта функционального покрытия 3 формируется по результатам анализа данных бухгалтерского учета компании за прошедшие периоды и содержит перечень типовых хозяйственных операций по участкам учета (включая операции, не учитываемые в бухгалтерском учете) и описание выбранного способа по отражению каждой конкретной операции на ПС МСФО в системе.

Способы отражения операций на ПС МСФО:

• конвертация данных бухгалтерского учета по правилам мэппинга;

• независимое от бухгалтерского учета ведение учета по МСФО:

— при помощи специального функционала, подлежащего автоматизации;

На основе разработанной методологии формируются функционально-технические требования к подсистеме МСФО в виде отдельного документа, который будет являться основой для разработки Технического задания программистам.

В целом для ведения учета и формирования отчетности в подсистеме МСФО должны быть предусмотрены следующие возможности 4 :

• автоматическое формирование проводок МСФО на основе проводок БУ по правилам мэппинга и формирование отчетов о результатах конвертации;

• формирование проводок МСФО в ручном режиме;

• учет основных средств и нематериальных активов в соответствии с МСФО (в том числе объектов в лизинге и инвестиционной собственности);

• учет операций по договорам подряда в соответствии с МСФО;

• расчет и признание оценочных резервов и начисленных обязательств в соответствии с МСФО;

• учет финансовых инструментов в соответствии с МСФО;

• учет операций со связанными сторонами в соответствии с МСФО;

• расчет отложенных налогов в соответствии с МСФО;

• расчет себестоимости по МСФО;

• формирование типовых отчетов по ПС МСФО;

• формирование индивидуальной отчетности по МСФО;

• выгрузка отчетных форм в MS Excel.

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

Метод трансформации

Трансформация данных — это процесс составления отчетности по МСФО путем перегруппировки учетной информации и корректировки статей отчетности, подготовленной по правилам РСБУ на отчетную дату (за отчетный период).

Трансформационные корректировки — бухгалтерские записи, позволяющие выполнить переход от отчетности по РСБУ к отчетности по МСФО на заданную дату (за заданный период). Бывают двух типов: реклассификационные и оценочные.

Оценочные корректировки выполняются путем пересчета сумм РСБУ и выполнения специальных расчетов для целей МСФО по отдельным участкам учета.

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

В первом случае архитектура решения будет иметь следующий вид (схема 3).

Схема 3. Подготовка консолидированной отчетности при трансформации данных БУ в формат МСФО

При этом сама консолидация опять же может выполняться как в MS Excel, так и в отдельном программном продукте, предназначенном для консолидации данных.

Во втором случае архитектура решения будет соответствовать схеме 4.

Схема 4. Подготовка консолидированной отчетности при трансформации и консолидации данных в одном программном продукте

Такой вариант предполагает, что отчетность по МСФО формируется в программном продукте МСФО следующим образом:

1. Из внешних источников (бухгалтерские базы или MS Excel) загружаются данные бухгалтерского учета в определенном формате по компаниям, входящим в периметр консолидации.

2. Выполняется автоматическая трансформация загруженных данных при помощи специально разработанного и настроенного функционала.

3. Выполняется автоматическая консолидация данных по нескольким компаниям.

4. Формируется консолидированная отчетность по МСФО (основные формы и расшифровки).

Для организации процесса подготовки отчетности по МСФО таким способом также потребуется разработать/адаптировать определенные методологические документы:

2. Карта соответствия (мэппинг) между ПС БУ и МСФО.

3. Нормативно-справочная информация, используемая для целей МСФО (справочники, классификаторы, перечисления и др.).

4. Альбом отчетных форм (с методикой формирования показателей).

5. Описание типовых корректировок по МСФО и методики их выполнения.

По сравнению с перечнем методологических документов, разрабатываемых при организации учета методом трансляции, новым в списке является документ по описанию корректировок. Данный документ должен содержать перечень трансформационных и консолидационных корректировок, выполняемых при подготовке отчетности по МСФО в группе компаний по участкам учета (включая операции, не учитываемые в российском бухгалтерском учете), и описание методики выполнения корректировок на ПС МСФО.

Типовые корректировки целесообразно описывать по участкам учета и по видам:

• Трансформационные корректировки (отдельно реклассификационные и оценочные).

Методика выполнения корректировок представляет собой описание правил выполнения корректировок:

• Случаи, когда выполняется корректировка.

• Периодичность выполнения корректировок.

• Проводка (бухгалтерская запись) по выполнению корректировки.

• Определение суммы проводки.

• Особенности выполнения корректировки.

В целом для выполнения трансформации и консолидации с последующим формированием консолидированной отчетности в программном продукте должны быть предусмотрены следующие возможности:

• Загрузка данных бухгалтерского учета из внешних источников (MS Excel, бухгалтерские базы).

• Наличие настраиваемых механизмов трансформации остатков и оборотов БУ на ПС МСФО.

• Автоматическое выполнение реклассификационных корректировок по правилам соответствия счетов БУ и МСФО.

• Автоматическое выполнение оценочных корректировок по участкам учета:

— учет основных средств и нематериальных активов в соответствии с МСФО;

— учет операций по договорам подряда;

— учет оценочных резервов и начисленных обязательств;

— учет финансовых инструментов;

— учет операций со связанными сторонами;

— учет отложенных налогов и др.

• Автоматическое выполнение сверки внутригрупповых остатков и оборотов и выполнение консолидационных корректировок.

• Ручное выполнение корректировок любого вида.

• Формирование трансформационных и консолидационных таблиц-ведомостей.

• Формирование индивидуальной/отдельной отчетности по МСФО по компаниям.

• Формирование консолидированной отчетности по МСФО по группе.

• Выгрузка отчетных форм в MS Excel.

Еще раз подчеркнем, что при автоматизации метода трансформации не будет автоматизировано потранзакционное ведение учета по МСФО (которое достигается при методе трансляции). Это значит, что трансформационные и консолидационные корректировки рассчитываются и выполняются по состоянию на дату подготовки отчетности по МСФО (на отчетную дату).

Сравнение методов

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

Плюсы и минусы методов трансформации и трансляции данных

Критерий

Автоматизация метода трансформации

Автоматизация метода трансляции

Менее точные данные, корректировки рассчитываются и выполняются по состоянию на отчетную дату (за отчетный период)

Более точные и прозрачные данные (так как ведется учет каждой операции, а не перекладка остатков и оборотов)

Степень агрегирования данных

В основном использование агрегированных показателей, без детализации.

По существенным операциям требуется дополнительный анализ

Пообъектный, поэлементный учет

Проверяемость данных (аудиторский след)

Переход до уровня первичного документа не поддерживается, так как обрабатываются агрегированные остатки и обороты, а не проводки.

Если бухгалтерский учет ведется в одной базе, а трансформация и консолидация выполняются в другой, то требуется проверка загрузки/выгрузки данных.Физически разделены источник данных для трансформации (БУ) и механизмы трансформации

По каждой операции можно увидеть, как она отражена в бухгалтерском учете и учете по МСФО.

Из каждой проводки МСФО можно перейти в документ-регистратор — документ МСФО или документ БУ, на основе которого сформирована проводка МСФО

Оперативность формирования данных

Требуется дождаться закрытия периода в БУ, после чего приступить к трансформации данных

Возможность формировать и анализировать данные МСФО в системе по мере необходимости.

Большая часть проводок МФСО формируется в режиме онлайн при проведении документов БУ

Изменение данных МСФО при изменении данных в БУ

При изменениях в данных БУ требуется заново выгрузить данные для трансформации, если трансформация осуществляется во внешней системе (автоматический пересчет не выполняется)

При изменении данных в БУ изменения автоматически отражаются в МСФО по заданным правилам.

Не требуются выгрузки данных во внешние системы, учет по БУ и МСФО ведется в едином программном продукте

Поддержка учета и отчетности в разных валютах

Выполняется пересчет данных по курсу на дату закрытия и среднему курсу за период.

По существенным операциям требуются ручной анализ и пересчет по историческим курсам

Выполняется пересчет по точечным курсам на конкретную дату.

Вмешательство в ручном режиме не требуется

Количество ручного труда при работе с системой

Требуются проверка корректности перегрузки данных и проверка работы алгоритмов трансформации и консолидации.

По неавтоматизированным корректировкам требуются ручные расчеты.

Если трансформация и консолидация организованы в отдельной базе, то специалистов по МСФО будет требоваться меньше, чем при ведении учета по МСФО в каждой компании.

Количество ручного труда зависит от степени автоматизации учета.

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

При детальной степени автоматизации задача по формированию МСФО сводится к последовательному выполнению ряда автоматизированных операций

Требуется разработка/адаптация методологии по выполнению трансформационных и консолидационных корректировок

Требуется разработка/адаптация методологии по ведению учета и формированию отчетности по МСФО в программном продукте

Взаимосвязь с другими системами (кроме БУ)

Возможность организовать бюджетирование и управленческий учет с использованием информации в учете по МСФО

Связь с функционалом по консолидации

Выполняется трансформация данных бухгалтерского учета, в котором может отсутствовать весомая часть информации, требуемой для трансформации и консолидации МСФО.

Этот объем потребует обработки в ручном режиме

В функционал по ведению учета по МСФО можно заложить возможности по упрощению дальнейшей консолидации (на уровне ПС, признаков контрагентов, выделения внутригрупповых продаж и пр.).

Консолидировать отчетность даже вручную, имея учет по МСФО, гораздо проще, чем сначала сделать трансформацию данных БУ, а потом консолидацию

Зависимость от вышестоящих организаций, последствия изменения учетных политик

При изменении учетной политики, а также форматов выгрузки/загрузки данных потребуется изменение механизмов трансформации и консолидации.

Технологически сложнее обеспечить сопоставимость сравнительных данных между периодами

Независимость от технической организации процесса подготовки данных по МСФО вышестоящими организациями (возможность автономного формирования отчетности по МСФО независимо от материнской компании согласно собственной методологии).

Гибкость в вопросах выгрузки данных для вышестоящих организаций в любых форматах и разрезах.

Подсистему МСФО проще адаптировать к новой учетной политике, автоматизировав операции по пересчету сопоставимых данных

Сроки реализации короче (примерно в 1,5 раза по сравнению со вторым способом)

Больше сроки реализации

Стоимость внедрения ниже по сравнению со вторым способом

Выше стоимость внедрения

Проще, дешевле, так как функционал проще и может быть сосредоточен в отдельном программном продукте (без установки в базу каждой компании)

Требуется полноценное сопровождение на уровне каждой компании. При изменениях в функционале БУ необходимо проводить мониторинг влияния изменений на блок МСФО

При этом следует отметить, что оба варианта формируют организационно-стратегические преимущества для компании, решившей автоматизировать подготовку отчетности по МСФО, по сравнению с компанией, в которой отчетность по МСФО формируется в ручном режиме. Так, наличие функционала по автоматизированной подготовке отчетности по МСФО:

• позволяет сократить затраты на привлечение внешних консультантов для подготовки отчетности по МСФО;

• позволяет сократить затраты на аудит отчетности по МСФО;

• повышает капитализацию компании/группы и является конкурентным организационным преимуществом.

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

На практике часто бывает нецелесообразным автоматизировать подготовку отчетности методом трансформации, так как этот метод можно успешно применять и при помощи всем хорошо известных средств MS Excel.

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

1. Мы не рассматриваем ведение учета по МСФО параллельным методом, когда каждая операция отдельно (независимо от других операций) регистрируется и обрабатывается в базе ведения бухгалтерского учета и в базе ведения учета по МСФО в силу того, что он является наименее востребованным и реализуемым на практике, так как требует дублирования учетных функций.

Метод трансляции это дублирование исключает, так как информация вносится один раз в базу бухгалтерского учета и далее обрабатывается для целей БУ и для целей МСФО.

2. Перечень приведен исходя из допущения о том, что компания ранее уже формировала отчетность по МСФО и имеет учетную политику по МСФО.

3. Подробно о назначении, структуре и содержании документов см.: Манько С. В. Автоматизация учета по МСФО: методологическая база проекта // КФО.МС. 2011. № 2.

4. Список может отличаться в части, касающейся отраслевой специфики и особенностей конкретной компании/группы.

5. При трансформации под мэппингом подразумеваются правила соответствия между данными БУ и МСФО, задаваемые в алгоритмах трансформации в программном продукте.

Источник