Мэппинг

Мэппинг в ERP, или два отчета в один клик

Настоящая Политика описывает то, как мы будем обрабатывать Ваши персональные данные, которые Вы предоставляете на сайте assino.ru. Используя сайт assino.ru, Вы соглашаетесь с условиями Политики. Если Вы не согласны с ее условиями, Вы можете в любой момент обратиться к нам для прекращения использования персональных данных.

Какой вид информации собирается на сайте:

1. Информация, которую Вы предоставляете на сайте assino.ru: Ваше имя, адрес электронной почты, контактный телефон. Другая информация может быть предоставлена на Ваше усмотрение или для предоставления отдельных услуг;
2. Данные, которые мы получаем автоматически в зависимости от настроек Вашего программного обеспечения: IP-адрес, cookies, параметры и настройки браузера, операционная система, URL-адрес, время посещения сайта, какие страницы просматривались, геопозиция.

Мы не проверяем достоверность предоставляемых Вами персональных данных. При необходимости, Вы можете изменить или дополнить предоставленную персональную информацию на нашем сайте.

Цели обработки

1. Предоставление персонализированного сервиса;
2. Предоставление доступа к услугам и интересующей Вас информации, которыми Вы выразите желание воспользоваться;
3. Поддержание связи с Вами: направление уведомлений, запросов и информации, касающихся использования сайта; обработка запросов и заявок; отправка по электронной почте маркетинговых сообщений assino.ru, относящихся к нашим услугам или услугам наших партнеров; информирование Вас об акциях и спецпредложениях;
4. Повышение качества сайта, клиентского сервиса и повышение удобства его использования.

Предоставление информации третьим лицам

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

Использование Сookies

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

При желании, Вы можете отказаться от использования технологий Сookies и запретить сохранение файлов на компьютере, которые предоставляют доступ к сайту assino.ru.

Безопасное хранение

1. Ваши персональные данные хранятся на защищенных серверах, которые предотвращают неавторизированный доступ к системам;
2. Способы сбора, хранения и обработки данных постоянно совершенствуются, включая физические меры безопасности для полного исключения несанкцианированного доступа к системам;
3. У сотрудников и подрядчиков компании есть ограничения к доступу данных, они могут использовать данные только для целей, указанных в Политике. Кроме того, на сотрудников и подрядчиков накладываются строгие договорные обязательства, за нарушение которых предусмотрены ответственность и штрафные санкции.

Прекращение обработки

Вы имеете право отказаться от обработки персональных данных путем письменного уведомления на адрес: 115114, г. Москва, ул. Кожевническая, дом № 7, строение 1, ООО «Ассино Имплементейшенс РУС», с пометкой «прекращение обработки персональных данных». Это повлечет за собой уничтожение Ваших персональных данных в системах, хранящих их. После отказа от обработки Вы не сможете пользоваться предоставленными ранее услугами и сервисами. Отписаться от email-рассылки рекламных и маркетинговых сообщений Вы можете в любое время, нажав на ссылку отказа от подписки в нижней части email-сообщения.

Автоматизация учета по МСФО: методологическая база проекта

Авторы публикации

Манько Снежана Владимировна

к.э.н., АССА, Сооснователь и методолог проекта FIN-SKILL.RU

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

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

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

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

Нужно концептуально продумать вопрос функциональной архитектуры!

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

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

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

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

4. Разработка/адаптация методических документов для работы в системе:

• – План счетов по МСФО.
• – Карта соответствия (мэппинг) данных по РСБУ и МСФО.
• – Нормативно-справочная информация и методика ее применения.
• – Альбом отчетных форм по МСФО и методика их заполнения.
• – Алгоритмы расчетов и формирования данных в системе (в том числе регламентные операции).
• – Методика загрузки начальных остатков в систему.
• – Регламент ведения учета по МСФО в компании и др.

5. Разработка проектной документации:

• – Функционально-технические требования к системе.
• – Техническое задание на разработку/доработку системы.
• – Программа и методика тестовых испытаний.
• – Руководство пользователя и администратора и др.

6. Тестирование разработанного функционала.

7. Обучение конечных пользователей.

8. Консультационное сопровождение на этапе эксплуатации.

9. Прохождение внешнего аудита информационной системы (если это необходимо).

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

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

На первых этапах проекта по автоматизации необходимо разработать и передать программистам следующие документы:

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

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

– выделить счета верхнего уровня и субсчета;

– организовать кодировку счетов. Наиболее часто встречаемые варианты:

• аналогия кодов МСФО с российскими кодами (например, счет 50 «Касса» РСБУ, счет F50 «Cash» в МСФО); для счетов, не имеющих аналогов, используются незанятые в РСБУ номера;
• привязка кодов МСФО к отчетным формам (например, статья «Основные средства» в балансе по МСФО имеет код 1100; соответственно, счет верхнего уровня для учета основных средств также будет иметь код 1000, а субсчет к нему – 1100.1, 1100.2 и т. д.);
• независимая кодировка счетов МСФО (М100 «Основные средства», М200 «НМА», М300 «Финансовые активы» и т. д.);

– определить язык наименования счетов (иногда используется один язык, иногда несколько);

– для каждого счета указать его тип (активный, пассивный, активнопассивный);

– описать аналитику (субконто) по каждому счету (например, для счета «Расчеты с поставщиками» целесообразно вести учет в разрезе контрагентов и договоров контрагентов; соответственно, субконто первого уровня – «Контрагенты», субконто второго уровня – «Договоры контрагентов»). Для этого целесообразно проанализировать российский план счетов на предмет организованных на нем субсчетов и аналитических признаков;

– выделить счета, по которым будет вестись не только суммовой, но и количественный учет (как правило, это счета, имеющие аналитику «Номенклатура»);

– выделить валютные счета, по которым будет вестись учет не только в функциональной валюте, но и в иностранных валютах.

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

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

Пример формата документа приведен в табл. 1.

Таблица 1

План счетов МСФО (пример формата)

Код	Наименование англ.	Наименование рус.	Вал.	Кол.	А/П	Субконто 1	Субконто 2	Субконто 3
	Intangible assets	Нематериальные активы
	Intangible assets – Costs	Нематериальные активы – первоначальная стоимость
		Гудвилл	–	–	А	НМА	–	–
	Other Intangible assets	Прочие нематериальные активы	–	–	А	НМА	–	–
	Intangible assets – Accumulated Depreciation	Нематериальные активы – накопленная амортизация
	Other Intangible assets	Прочие нематериальные активы	–	–	П	НМА	–	–
	Intangible assets – Accumulated Impairment	Нематериальные активы – накопленное обесценение
		Гудвилл	–	–	П	НМА	–	–
	Other Intangible assets	Прочие нематериальные активы	–	–	П	НМА	–	–

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

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

Каждая операция определенным образом регистрируется в системе, например отражается на счетах бухгалтерского учета: определяются проводка, сумма проводки, документ-регистратор этой проводки, выполняется запись. Другой пример, без формирования проводок, – изменение характеристик объекта, например срока полезного использования или метода начисления амортизации: в карточках объектов или в специальных регистрах меняются сведения.

Чтобы сформировать перечень типовых хозяйственных операций по МСФО, необходимо:

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

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

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

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

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

Пример формата документа приведен в табл. 2.

Таблица 2

Карта функционального покрытия (пример формата)

Код	Дт	Наименование	Кт	Наименование		Отражение в МСФО
		Собственные основные средства		Строительство объектов ОС	Ввод в эксплуатацию ОС	Документ МСФО «Принятие к учету ОС МСФО»
		Собственные основные средства		Приобретение отдельных объектов ОС, не требующих компл. сборки	Ввод в эксплуатацию ОС	Документ МСФО «Принятие к учету ОС МСФО»
		Собственные основные средства		По текущим операциям	Авизо входящее (филиал)	Конвертация из РСБУ
		Выбытие основных средств		Собственные основные средства	Списание, выбытие ОС	Документ МСФО «Выбытие ОС МСФО»
		По выделенному имуществу		Собственные основные средства	Авизо исходящее (филиал)	Конвертация из РСБУ
		Амортизация собственных основных средств		Выбытие основных средств	Списание, выбытие ОС (амортизация)	Документ МСФО «Выбытие ОС МСФО»
		Прочие расходы		Амортизация собственных основных средств	Начисление амортизации	Документ МСФО «Амортизация ОС МСФО»
		Основное производство		Амортизация собственных основных средств	Начисление амортизации	Документ МСФО «Амортизация ОС МСФО»
		Вспомогательные производства		Амортизация собственных основных средств	Начисление амортизации	Документ МСФО «Амортизация ОС МСФО»
		Общепроизводственные расходы		Амортизация собственных основных средств	Начисление амортизации	Документ МСФО «Амортизация ОС МСФО»
		Общехозяйственные расходы		Амортизация собственных основных средств	Начисление амортизации	Документ МСФО «Амортизация ОС МСФО»

3. Карта соответствия (мэппинг) данных по РСБУ и МСФО.

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

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

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

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

При подготовке Карты соответствия отдельно следует описать правила приоритета, например: наивысший приоритет имеют проводки, содержащиеся в списке «Исключаемые из конвертации», приоритет следующего порядка – проводки, для которых задано самое полное соответствие (например, проводке Дт 70 «Расчеты с персоналом», Кт «Касса» соответствует проводка МСФО Дт F70, Кт F50, при этом значения субконто к счетам МСФО равны значениям субконто счетов РСБУ), приоритет нижнего уровня – прочие соответствия.

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

Разработку мэппинга следует поручить внешним методологам проекта с последующим согласованием со стороны заказчика.

Примеры форматов документов приведены в табл. 3 и 4 (см. приложение).

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

Под НСИ понимаются константы, справочники и регистры, которые потребуются для ведения учета по МСФО.

Большая часть НСИ, как правило, уже используется в системе РСБУ и может быть применена и для МСФО, например справочники «Контрагенты», «Номенклатура», «НМА и РБП» и др. Иногда для целей МСФО требуется доработать реквизиты в этих справочниках, например в карточке контрагента добавить признак «Компания группы» или «Связанная сторона» для построения отчетов, характерных для МСФО.

В документе «Нормативно-справочная информация» следует описать:

1) объекты, которые имеются в системе РСБУ и будут использоваться в МСФО без доработок и изменений;

2) объекты, имеющиеся в системе РСБУ, по которым потребуется доработка каких-либо реквизитов/параметров для целей МСФО;

3) объекты, характерные для МСФО и отсутствующие в системе РСБУ. Так, часто встречаются на практике:

• – константа «Дата запрета редактирования МСФО»;
• – константа «Ставка дисконтирования МСФО»;
• – справочники «Соответствие счетов» и «Исключение проводок»;
• – справочник «Основные средства МСФО»;
• – регистр «Результаты переоценки МСФО» и др.

Разработку НСИ целесообразно поручить внешним методологам проекта с последующим согласованием со стороны заказчика.

5. Правила учета специфических операций.

Речь идет в основном об операциях, требующих применения бухгалтерских оценок, например:

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

– обесценение активов (какую ставку дисконтирования использовать, как определять справедливую стоимость объектов, на какие активы и в какой пропорции распределять убыток);

– учет лизинга (каким способом распределять процентную составляющую);

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

– расчет резервов (по каким формулам рассчитывать оценочные резервы каждого вида);

– механизмы консолидации данных (если требуется подготовка консолидированной отчетности).

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

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

6. Альбом форм отчетности по МСФО и методика формирования показателей.

Результатом автоматизации учетного процесса может быть:

1) типовая Оборотно-сальдовая ведомость, построенная по Плану счетов МСФО, с сопутствующими расшифровками (ОСВ по счету, анализ счета, карточка счета, анализ субконто и др.);

2) пакет отчетности по МСФО (Отчет о финансовом положении, Отчет о совокупном доходе, ОДДС, Отчет об изменениях капитала и расшифровки к ним).

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

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

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

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

1) Методика расчета и загрузки на План счетов МСФО начальных остатков.

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

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

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

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

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

2) Регламент по ведению учета по МСФО в компании с использованием автоматизированной системы (Требования к методике ведения учета).

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

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

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

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

Приложение

Таблица 3

Карта соответствия данных РСБУ и МСФО (пример формата)

Дт/ Кт

Счет РСБУ

Дополнительныеусловия мэппинга

Счет МСФО

Правила заполнения

Сумма проводки

Код

Наиме-нование

Суб- конто 1

Суб- конто 2

Суб- конто 3

Кор. счет

Код

Наиме-нование

Суб- конто 1

Суб- конто 2

Суб- конто 3

Запол- нение субконто

Дт

Обору-дование к установке

Номен-клатура

Места хранения

Любой

Construction in progress (CIP) nomenclature

Номен-клатура

Места хранения

Значение субконто РСБУ

Правило для корр. счета

Кт

Обору-дование к установке

Номен-клатура

Места хранения

Любой

Construction in progress (CIP) nomenclature

Номен-клатура

Места хранения

Значение субконто РСБУ

= СКД $ на счете МСФО х кол-во в проводке / кол-во по заданному субконто

Дт

Расч. с пост. в руб.

Контр-агенты

Основа- ние

Счета-фактуры получ.

Любой, кроме 60.11

Trade payables in RUB

Контр-агенты

Основание

Счета-фактуры получ.

Значение субконто РСБУ

= СКК $ на счете МСФО х сумма проводки руб. / СКК на счете РСБУ по заданному субконто

Дт

Расч. с пост. в руб.

Контр-агенты

Основа- ние

Счета-фактуры получ.

Trade payables in RUB

Контр-агенты

Основание

Счета-фактуры получ.

Значение субконто РСБУ

Правило для корр. счета

Кт

Расч. с пост. в руб.

Контр-агенты

Основа- ние

Счета-фактуры получ.

Любой

Trade payables in RUB

Контр-агенты

Основание

Счета-фактуры получ.

Значение субконто РСБУ

= Сумма проводки руб. / текущий курс $

Дт

Недост. от порчи ценностей

Сотруд- ники

–

–

Любой

Other expenses

Виды доходов и расходов

–

–

= «Инвента-ризация, недостачи»

Правило для корр. счета

Кт

Недост. от порчи ценностей

Сотруд- ники

–

–

Любой

Other expenses

Виды доходов и расходов

–

–

= «Инвента-ризация, недостачи»

= Сумма проводки руб. // текущий курс $

Таблица 4

Проводки РСБУ, исключенные из конвертации (пример формата)

Дт/Кт	Счет РСБУ			Корр. счет РСБУ		Причина исключения
	Код	Наименование	Субконто 1	Код	Наименование
Кт		Собственные основные средства	–	Любой	–	Выбытие ОС – отдельный документ МСФО
Дт/Кт		Выбытие основных средств	–	Любой	–	Выбытие ОС – отдельный документ МСФО
Дт/Кт		Амортизация основных средств	–	Любой	–	Начисление амортизации – отдельный документ МСФО
Кт		Основное производство	–	Любой	–	Закрытие месяца – отдельный документ МСФО
Дт/Кт		Резервы по сомнительным долгам	–	Любой	–	Отдельный расчет по МСФО
Кт		Прочие доходы	= Курсовые разницы	Любой	–	Закрытие месяца – отдельный документ МСФО
Дт		Прочие расходы	= Курсовые разницы	Любой	–	Закрытие месяца – отдельный документ МСФО

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

Полная автоматизация – автоматизация всех участков учета и формирования отчетности. Частичная автоматизация – автоматизация учета отдельных участков (как правило, наиболее объемных и трудоемких) с выгрузкой данных из системы для дальнейшей обработки, например, в MS Excel.

Полностью независимый от РСБУ учет. На практике способ редко оправдан, так как большую часть данных можно транслировать/конвертировать из РСБУ, поскольку операции компании одинаковы независимо от системы учета.

Соответствие между документами описывается, если принято решение проводки МСФО формировать документами МСФО, создаваемыми на основе документов РСБУ. Если проводки МСФО будут записываться в документы РСБУ или формироваться одним универсальным документом МСФО (типа «Бухгалтерская справка МСФО»), то мэппинг документов не требуется.

Часть 2. Создание классов, маппингов и заполнение БД

КЛАССЫ И МАППИНГИ
Уроки по FluentNHibernate c ASP.NET MVC и SQL Server. Часть 1
Часть 3. Отображение данных из таблицы (Операция LIST)
В предыдущей части были рассмотрены виды связей (один-к-одному, один-ко-многим, многие-ко-многим), а также один класс Book и его маппинг-класс BookMap. Во второй части обновим класс Book, создадим остальные классы и связи между ними, как это было изображено в предыдущей главе в Диаграмме баз данных, расположившейся над подзаголовком 1.3.1 Связи.
Код классов и маппингов (С комментариями) Класс Книга
public class Book { //Уникальный идентификатор public virtual int Id { get; set; } //Название public virtual string Name { get; set; } //Описание public virtual string Description { get; set; } //Оценка Мира фантастики public virtual int MfRaiting { get; set; } //Номера страниц public virtual int PageNumber { get; set; } //Ссылка на картинку public virtual string Image { get; set; } //Дата поступления книги (фильтр по новинкам!) public virtual DateTime IncomeDate { get; set; } //Жанр (Многие-ко-Многим) //Почему ISet а не IList? Только одна коллекция (IList) может выбираться с помощью JOIN выборки, если нужно более одной коллекции для выборки JOIN, то лучше их преобразовать в коллекцию ISet public virtual ISet<Genre> Genres { get; set; } //Серия (Многие-к-одному) public virtual Series Series { get; set; } //Мнение и другое (Один-к-одному) private Mind _mind; public virtual Mind Mind { get { return _mind ?? (_mind = new Mind()); } set { _mind = value; } } //Автор (Многие-ко-многим) public virtual ISet<Author> Authors { get; set; } //Заранее инициализируем, чтобы исключение null не возникало. public Book() { //Неупорядочное множество (в одной таблице не может присутствовать две точь-в-точь одинаковые строки, в противном случае выбирает одну, а другую игнорирует) Genres = new HashSet<Genre>(); Authors = new HashSet<Author>(); } } //Маппинг класса Book public class BookMap : ClassMap<Book> { public BookMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.Description); Map(x => x.MfRaiting); Map(x => x.PageNumber); Map(x => x.Image); Map(x => x.IncomeDate); //Отношение многие-ко-многим HasManyToMany(x => x.Genres) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и //создаются/обновляются/добавляются все зависимые объекты .Cascade.SaveUpdate() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Genre! .Table(«Book_Genre»); HasManyToMany(x => x.Authors) .Cascade.SaveUpdate() .Table(«Book_Author»); //Отношение многие к одному References(x => x.Series); //Отношение один-к-одному. Главный класс. HasOne(x => x.Mind).Cascade.All().Constrained(); } }
Класс Автор
public class Author { public virtual int Id { get; set; } //Имя-Фамилия public virtual string Name { get; set; } //Биография public virtual string Biography { get; set; } //Книжки public virtual ISet<Book> Books { get; set; } //Инициализация Авторов public Author() { Books=new HashSet<Book>(); } } //Маппинг Автора public class AuthorMap : ClassMap<Author> { public AuthorMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.Biography); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты .Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table(«Book_Author»); } }
Класс Жанр
public class Genre { public virtual int Id { get; set; } //Название жанра public virtual string Name { get; set; } //Английское название жанра public virtual string EngName { get; set; } //Книжки public virtual ISet<Book> Books { get; set; } //Инициализация книг public Genre() { Books=new HashSet<Book>(); } } //Маппинг жанра public class GenreMap : ClassMap<Genre> { public GenreMap() { Id(x => x.Id); Map(x => x.Name); Map(x => x.EngName); //Отношение многие-ко-многим HasManyToMany(x => x.Books) //Правила каскадирования All — Когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты .Cascade.All() //Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() //Название промежуточной таблицы ДОЛЖНО быть как и у класса Book! .Table(«Book_Genre»); } }
Класс Мнение:
public class Mind { public virtual int Id { get; set; } //Мое мнение public virtual string MyMind { get; set; } //Мнение фантлаба public virtual string MindFantLab { get; set; } //Книга public virtual Book Book { get; set; } } //Маппинг Мind public class MindMap:ClassMap<Mind> { public MindMap() { Id(x => x.Id); Map(x => x.MyMind); Map(x => x.MindFantLab); //Отношение один к одному HasOne(x => x.Book); } }
Класс Цикл(Серия):
public class Series { public virtual int Id { get; set; } public virtual string Name { get; set; } //Я создал IList, а не ISet, потому что кроме Book, Series больше ни с чем не связана, хотя можно сделать и ISet public virtual IList<Book> Books { get; set; } //Инициализация книг. public Series() { Books = new List<Book>(); } } public class SeriesMap : ClassMap<Series> { public SeriesMap() { Id(x => x.Id); Map(x => x.Name); //Отношение один-ко-многим HasMany(x => x.Books) ////Владельцем коллекции явл. другой конец отношения (Book) и он будет сохранен первым. .Inverse() } }
Небольшое объяснение
public virtual ISet<Genre> Genres { get; set; }
public virtual ISet<Author> Authors { get; set; }
Почему ISet<Class>, а не, к примеру, привычный многим IList<Class>? Если использовать вместо ISet — IList, и попробовать запустить проект, то разницы особой мы не заметим (Таблицы и классы создадутся). Но когда мы к классу Book LeftJoin-им одновременно таблицу Genre и Authors, да и еще пытаемся вывести неповторяющиеся записи из таблицы Book (Distinct Book.Id) в представление (View), Nhibernate выдаст исключение и ошибку.
Cannot simultaneously fetch multiple bags.
В таких случаях используем ISet, тем более множества для этого и предназначены (игнорируют дублирующие записи).
Отношение многие-ко-многим.

В NHibernate есть понятие, «главной» таблицы. Хотя отношения «многие-ко-многим» между таблицами “Book” и “Автор” равнозначны (У автора может быть много книг, у книги может быть множество авторов), Nhibernate требует, чтобы программист указывал таблицу, которая сохраняется второй (имеет метод .inverse()), то есть вначале будет создана/обновлена/удалена запись в таблице Book, а только потом в таблице Author.
Cascade.All означает выполнение каскадных операций при save-update и delete. То есть когда объект сохраняется, обновляется или удаляется, проверяются и создаются/обновляются/добавляются все зависимые объекты (Ps. Можно прописать вместо Cascade.All -> .Cascade.SaveUpdate().Cascade.Delete())
Метод .Table(«Book_Author»); создает «промежуточную» таблицу “Book_Author” в БД.
Отношение многие-к-одному, один-ко-многим.

Book	Series
References(x => x.Series).Cascade.SaveUpdate();	HasMany(x => x.Books) .Inverse();

Метод References применяется на стороне «Многие-к-одному», на другой стороне «Один-ко-многим» будет метод HasMany.
Отношение один-к-одному

Book	Mind
HasOne(x => x.Mind).Cascade.All().Constrained();	HasOne(x => x.Book);

Метод .Constrained() говорит NHibernate, что для записи из таблицы Book должна соответствовать запись из таблицы Mind (id таблицы Mind должен быть равен id таблицы Book)
Если сейчас запустить проект и посмотреть БД Bibilioteca, то появятся новые таблицы с уже сформированными связями.

Далее заполним созданные таблицы данными…
Для этого создадим тестовое приложение, которое будет сохранять данные в БД, обновлять и удалять их, изменив HomeController следующим образом (Ненужные участки кода комментируем):
public ActionResult Index() { using (ISession session = NHibernateHelper.OpenSession()) { using (ITransaction transaction = session.BeginTransaction()) { //Создать, добавить var createBook = new Book(); createBook.Name = «Metro2033»; createBook.Description = «Постапокалипсическая мистика»; createBook.Authors.Add(new Author { Name = «Глуховский» }); createBook.Genres.Add(new Genre { Name = «Постапокалипсическая мистика» }); createBook.Series = new Series { Name = «Метро» }; createBook.Mind = new Mind { MyMind = «Постапокалипсическая мистика» }; session.SaveOrUpdate(createBook); //Обновить (По идентификатору) //var series = session.Get<Series>(1); //var updateBook = session.Get<Book>(1); //updateBook.Name = «Metro2034»; //updateBook.Description = «Антиутопия»; //updateBook.Authors.ElementAt(0).Name = «Глуховский»; //updateBook.Genres.ElementAt(0).Name = «Антиутопия»; //updateBook.Series = series; //updateBook.Mind.MyMind = «11111»; //session.SaveOrUpdate(updateBook); //Удаление (По идентификатору) //var deleteBook = session.Get<Book>(1); //session.Delete(deleteBook); transaction.Commit(); } Genre genreAl = null; Author authorAl = null; Series seriesAl = null; Mind mindAl = null; var books = session.QueryOver<Book>() //Left Join с таблицей Genres .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Authors, () => authorAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Series, () => seriesAl, JoinType.LeftOuterJoin) .JoinAlias(p => p.Mind, () => mindAl, JoinType.LeftOuterJoin) //Убирает повторяющиеся id номера таблицы Book. .TransformUsing(Transformers.DistinctRootEntity).List(); return View(books); } }
Небольшое объяснение

1. var books = session.QueryOver<Book>() — подобно выполнению скрипта SQL: Select * From Book;
2. .JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin) — подобно выполнению скрипта SQL:
   SELECT *FROM Book
   inner JOIN Book_Genre ON book.id = Book_Genre.Book_id
   LEFT JOIN Genre ON Book_Genre.Genre_id = Genre.id
3. .TransformUsing(Transformers.DistinctRootEntity) — Подобно выполнению скрипта SQL: SELECT distinct Book.Id…, (убирает дублирующие записи с одинаковыми id)

Виды объединений
.JoinAlias(p => p.Genres, () => genreAl, JoinType.LeftOuterJoin)

1. LeftOuterJoin — выбирает все записи из левой таблицы (Book), а затем присоединяет к ним записи правой таблицы (Genre). Если не найдена соответствующая запись в правой таблицы, отображает её как Null
2. RightOuterJoin действует в противоположность LEFT JOIN — выбирает все записи из правой таблицы (Genre), а затем присоединяет к ним записи левой таблицы (Book)
3. InnerJoin — выбирает только те записи из левой таблиц (Book) у которой есть соответствующая запись из правой таблицы (Genre), а затем присоединяет к ним записи из правой таблицы

Изменим представление следующим образом:
Представление index @model IEnumerable<NhibernateMVC.Models.Book> @{ Layout = null; } <!DOCTYPE html> <html> <head> <meta name=»viewport» content=»width=device-width» /> <title>Index</title> <style> th, td { border: 1px solid; } </style> </head> <body> <p>@Html.ActionLink(«Create New», «Create»)</p> <table> <tr> <th>@Html.DisplayNameFor(model => model.Name)</th> <th>@Html.DisplayNameFor(model => model.Mind)</th> <th>@Html.DisplayNameFor(model => model.Series)</th> <th>@Html.DisplayNameFor(model => model.Authors)</th> <th>@Html.DisplayNameFor(model => model.Genres)</th> <th>Операции</th> </tr> @foreach (var item in Model) { <tr> <td>@Html.DisplayFor(modelItem => item.Name)</td> <td>@Html.DisplayFor(modelItem => item.Mind.MyMind)</td> @{string strSeries = item.Series != null ? item.Series.Name : null;} <td>@Html.DisplayFor(modelItem => strSeries)</td> <td> @foreach (var author in item.Authors) { string strAuthor = author != null ? author.Name : null; @Html.DisplayFor(modelItem => strAuthor) <br /> } </td> <td> @foreach (var genre in item.Genres) { string strGenre = genre!= null ? genre.Name : null; @Html.DisplayFor(modelItem => strGenre) <br /> } </td> <td> @Html.ActionLink(«Edit», «Edit», new { id = item.Id }) | @Html.ActionLink(«Details», «Details», new { id = item.Id }) | @Html.ActionLink(«Delete», «Delete», new { id = item.Id }) </td> </tr> } </table> </body> </html>
Проверив поочередно все операции, мы заметим, что:

• При операциях Create и Update обновляются все данные, связанные с таблицей Book (уберите Cascade=»save-update» или cascade=»all» и связанные данные не будут сохранены)
• При удалении удаляются данные из таблиц Book, Mind, Book_Author, а остальные данные не удаляются, потому что у них Cascade=»save-update»
• При удалении удаляются данные из таблиц Book, Mind, Book_Author, а остальные данные не удаляются, потому что у них Cascade=»save-update»

Маппинг для классов, у которых есть наследование.
А как маппить классы у которых есть наследование? Допустим, имеем такой пример:
//Класс Двумерных фигур public class TwoDShape { //Ширина public virtual int Width { get; set; } //Высота public virtual int Height { get; set; } } //Класс треугольник public class Triangle : TwoDShape { //Идентификационный номер public virtual int Id { get; set; } //Вид треугольника public virtual string Style { get; set; } }
В принципе, ничего сложного в этом маппинге нет, мы просто создадим один маппинг для производного класса, то есть таблицы Triangle.

Формирование отчетности компании с использованием «мэппинга»

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

• разработка и реализация бизнес-стратегии;
• осуществление планирования и контроля;
• эффективное использование ресурсов;
• повышение эффективности деятельности;
• сохранение материальных и нематериальных активов;
• корпоративное и внутрифирменное управление бизнес-процессами

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

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

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

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

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

Необходимость для предприятия формировать отчетность по Международным стандартам может только усугубить ситуацию.

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

Возможны следующие варианты организации взаимосвязи:

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

Первый вариант организации взаимосвязи информационных учетных систем с формами отчетности (посредством таблиц описания взаимосвязей) называется «мэппинг».

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

Пример 1. Смешанный вариант организации взаимосвязи.

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

Отчетность трансформируется, как минимум в четыре этапа с использованием таблиц мэппинга и ручных корректировок.

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

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

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

4 –й этап. Подготовка описательной части отчета.

Таблица 1. Иллюстрация взаимоувязки российского плана счетов бухгалтерского учета с планом счетов GAAP (извлечение)

Показать всю таблицу

	Продажи – основная деятельность		Sales/revenues – main activity
90,1	Инвестиционный департамент (облагаемый)		Investm. Depart (Deductible)
90,16	Департамент оценки		Valuat dept. (deductible)
90,17	Исследовательский департамент (облагаемый)		Research dept. (deductible)
90,3	НДС по реализации НДС
90,31	НДС – услуги		Cons services VAT
Итого выручка			Gross Sales/revenues
	Себестоимость реализации
90,2	Себестоимость реализации		Investm. Depart (Deductible)
90,5	Прочие налоги начисленные (НсП)		Other tax collection
42,1	Торговая наценка (скидка, накидка)		The trade margin (discount, addition)
42,2	Скидка поставщиков на возмещение транспортных расходов		The discount of the suppliers on redress of transportation costs
91,1	Реализация и выбытие основных средств		Disposal of fixed assets
91,2	Реализация прочих активов		Disposal of other assetses
	Валовая прибыль		Net sales
	Общие, коммерческие и административные расходы		Selling general and administrative expenses
	Основное производство		The basic production
	Вспомогательное производство		Supplementary productions
	Общепроизводственные расходы		General production expenditures
26,70	Департамент маркетинга (облагаемый)		Market Depart (Deductible)
26,71	Департамент маркетинга (необлагаемый)		Market Depart (nonDeduclible)

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

Основой настройки мэппинга является определенным образом (согласно принятым в компании стандартам) сгруппированные данные учета.

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

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

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

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

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

Безусловно, на практике увязка показателей (мэппинг) управленческого, налогового и бухгалтерского (финансового) учета вызывает массу проблем.
Рассмотрим некоторые из них.

1. Нехватка аналитики в рабочем плане счетов (далее РПС) фирмы.

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

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

1. финансовой (бухгалтерской);
2. налоговой;
3. управленческой.

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

Возможные трактовки финансовой, налоговой и управленческой составляющих системного подхода к РПС представлены ниже.

Финансовая (бухгалтерская) составляющая. Использование РПС должно обеспечить возможность формирования всех (без исключения) результатных учетно-аналитических показателей внешней финансовой отчетности и пояснительной записки в разрезе бухгалтерских счетов Главной книги на отчетную дату. Блок бухгалтерских счетов РПС, задействованных для формирования внешней бухгалтерской отчетности, – это финансовые счета. В свою очередь, финансовые счета подразделяются на аналитические и синтетические. Субсчета финансового учета РПС являются промежуточными между аналитическими и синтетическими. Причем финансовые аналитические и синтетические счета, а также субсчета могут представлять собой неотъемлемую часть управленческой составляющей РПС. Так, например, данные, отраженные на отдельных субсчетах финансового счета 90 «Продажи», имеют важное значение для принятия управленческих решений.

При формировании группы финансовых счетов РПС необходимо выполнить следующие требования:

1. между статьями внешней бухгалтерской отчетности и остатками на финансовых счетах должно быть установлено такое соответствие, которое не требует дополнительных логических операций для определения типа статьи отчетности;
2. минимальный из возможных набор финансовых счетов РПС необходимо целенаправленно формировать исходя из состава показателей внешней финансовой отчетности;
3. каждый показатель внешней финансовой отчетности должен быть получен из данных финансового учета с использованием РПС без каких-либо дополнительных расшифровок и корректировок.

Налоговая составляющая. Применение РПС в системе бухгалтерского учета обеспечивает возможность исчислять налоговую базу и величину прибыли для целей налогообложения в соответствии с требованиями гл. 25 НК РФ. Реализация налоговой составляющей системного подхода к РПС предполагает:

1. организацию аналитического финансового и налогового учета расходов и доходов с целью выявления их влияния на величину налогооблагаемой базы для исчисления налога на прибыль коммерческой организации путем детализации финансовых счетов (01 – 99) РПС;
2. разработку перечня налоговых счетов (например, 101–199). Их внедрение даст возможность вести учет отклонений учетных данных объектов финансового и налогового учета с целью создания на базе финансового учета и финансовой отчетности налогового учета и налоговой отчетности;
3. разработку правил, позволяющих откорректировать влияние налоговой составляющей на единую интегрированную бухгалтерскую отчетность с целью исключения дублирования отчетных (результатных) учетно-аналитических показателей.

Управленческая составляющая. В РПС для получения результатных учетно-аналитических показателей управленческой внутренней отчетности и ведения управленческого учета выделяется блок управленческих счетов (например, 201–299). На этих управленческих счетах осуществляется двойная запись регулировок к финансовым счетам 01–99 исходя из требований, предъявляемых пользователями к внутренней управленческой отчетности. В дальнейшем данные на управленческих счетах 201–299 при использовании определенных правил дополняют (корректируют) данные на финансовых счетах 01–99. Результатом таких действий являются показатели внутренней управленческой отчетности.

Реализация управленческого аспекта в системном подходе к формированию РПС предполагает разработку:

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

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

Таблица 2. Мэппинг операций российского бухгалтерского (финансового) учета для формирования строк формы корпоративной отчетности «Баланс» (извлечение)

Показать всю таблицу

№	Строка Баланса	Счет БУ	Отбор по субконто 1	Корр. счет БУ	Отбор по субконто 1	Формула отбора
		Отбор по субконто 2		Отбор по субконто 2	Инвертировать знак
		Отбор по субконто 3		Отбор по субконто 3	Учет НДС
		Отбор по субконто 4		Отбор по субконто 4	Разворачивать по
		Отбор по субконто 5		Отбор по субконто 5	Участие в групповом счете
BL00102 Введено в эксплуатацию (+)						В групповом контроле участвует с плюсом
				Основные Средства: Прочие основные фонды		Объекты Строительства (р): Вид Поступления ОС (Поступление от сторонних организаций)	Дебетовый оборот
	Введено в эксплуатацию (+)		ОС в организации	Группы ОС: <все>	Вложено во внеоборотные активы		Не изменять
		Подразделения: <все>			Без изменений
		Код Проекта: <все>			Не разворачивать
					В групповом контроле участвует с плюсом
				Основные Средства: Прочие основные фонды		Объекты Строительства (р): Вид Поступления ОС (Поступление от сторонних организаций)	Дебетовый оборот
	Введено в эксплуатацию (+)		ОС без регистрации	Группы ОС: <все>	Вложено во внеоборотные активы		Не изменять
		Подразделения: <все>			Без изменений
		Код Проекта: <все>			Не разворачивать
					В групповом контроле участвует с плюсом
				Основные Средства: Прочие основные фонды		Объекты Строительства (р): Вид Поступления ОС (Поступление от сторонних организаций)	Дебетовый оборот
	Введено в эксплуатацию (+)		МЦ в организации		Вложено во внеоборотные активы		Не изменять
					Без изменений
					Не разворачивать
					В групповом контроле участвует с плюсом
				Основные Средства(р): Вид Поступления ОС (Поступление от сторонних организаций)		Объекты Строительства (р): Вид ПоступленияОС (Поступление от сторонних организаций)	Дебетовый оборот
	Введено в эксплуатацию (+)		МЦ, перед. во временное владение	Контрагенты: <все>	Вложено во внеоборотные активы		Не изменять
		Договоры: <все>			Без изменений
		Код Проекта: <все>			Не разворачивать
					В груповом контроле участвует с плюсом
				Основные Средства: Прочие основные фонды		Объекты Строительства (р): Вид ПоступленияОС (Поступление от сторонних организаций)	Дебетовый оборот
	Введено в эксплуатацию (+)		МЦ, перед. во временное пользование	Контрагенты: <все>	Вложено во внеоборотные активы		Не изменять
		Договоры: <все>			Без изменений
		Код Проекта: <все>			Не разворачивать
					В групповом контроле участвует с плюсом

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

• единый интегрированный план счетов финансового, налогового и управленческого учета;
• интегрированный план счетов финансового и налогового учета, автономный план счетов управленческого учета;
• интегрированный план счетов финансового и управленческого учета; автономный план счетов налогового учета;
• интегрированный план счетов налогового и управленческого учета; автономный план счетов финансового учета;
• автономные планы счетов финансового, налогового, управленческого учета.

2. Проблемы построения справочников и классификаторов, основными из которых являются:

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

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

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

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

– Несовместимость частей автоматизированной системы учета.
Например, снабжающее подразделение ведет регистры и справочники МТЦ в программе Cache, а бухгалтерские (финансовые) и управленские регистры, справочники ведутся в SAP R3, там же формируется отчетность компании. Форматы представления данных в этих программах различны, поэтому конвертация данных между ними затруднена, а в некоторых случаях напрямую невозможна.

При разработке справочников следует придерживаться следующих принципов.

– Детализация и структура справочников должна быть такой, чтобы можно было быстро обрабатывать данные и формировать требуемые отчеты.

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

Если справочник сильно детализирован, то его тяжело наполнять информацией и использовать в работе. Например, справочник «Движение денежных средств» может содержать более тысячи различных назначений платежа. Подготовка отчета о движении денежных средств по основным платежам для генерального директора потребует много времени, поскольку придется провести необходимую группировку (укрупнение показателей или выборку необходимой из массива избыточной информации). Кроме того, при вводе информации пользователь может не знать, куда необходимо отнести тот или иной платеж. Это неизбежно приведет к неверному выбору позиций из справочника или отнесению платежа к «прочим». Можно порекомендовать детально описать, какие объекты учета могут быть отражены по каждой строке справочника.

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

– Следует избегать использования похожих кодировок в разных справочниках.
Например, если при анализе продаж отдел маркетинга выделяет группы покупателей не по регионам, а по городам и областям, то группы для анализа не должны совпадать с кодами федеральных регионов. В противном случае это приведет к ошибкам при вводе информации. Так, для Москвы установлен код «77», а на предприятии под этим кодом числится Белгородская область. В результате сотрудник может отнести определенный вид продаж не к области, а к Москве, и информация будет искажена. В данном случае рекомендуется создавать коды разной длины, например для кодировки маркетинговых групп использовать три цифры (код «770» для клиентов Белгородской области);

– В идеале код справочника не должен превышать 8 символов. В противном случае данные сложно вводить, так как коды нелегко отличить друг от друга.

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

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

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

1. Ошибки, которые появятся из-за ранее описанных проблем.
2. Ошибки ведения бухгалтерского учета (как методологические, так и счетные). Учет ведут люди, не надо это забывать.
3. Далее следовало бы привести длинный перечень различных вариантов ошибок, источником которых будут результаты наложения п. 1 и 2. Однако, на наш взгляд, это излишне.

 

Михаил Литвиненко,
доцент Высшей Школы Финансового Менеджмента Академии Народного Хозяйства при Правительстве РФ, к. э. н.

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

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

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

Платформа ОФД 📌 РекламаОФД со скидкой 30%. Новогодняя акция на подключение касс ОФД поможет бухгалтеру сдать отчеты + аналитика продаж + работа с Честным ЗНАКом Узнать больше

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

Существует несколько методов объединения компаний в группу: полная консолидация, долевой метод учета и пропорциональная консолидация.

Дочерние компании: полная консолидация

При этой форме объединения материнская компания контролирует, или точнее, управляет дочерней. Под контролем (управлением) понимают возможность определять финансовую и хозяйственную политику фирмы с целью получения экономических выгод от её деятельности.Центр образования «Основы Вашего Бизнеса» 📌 РекламаСеминар: осваиваем нововведения в бухгалтерском учете. Самые главные и важные изменения в бухучете в 2020 году. Уникальная информация. Узнать больше

Одна компания контролирует другую, если:

• владеет (на праве собственности) более 50 процентами акций, имеющих право голоса;
• фактически контролирует более 50 процентов акций, имеющих право голоса;
• имеет возможность определять состав совета директоров;
• может определять финансовую и хозяйственную политику общества на основании законодательного акта или соглашения;
• обладает правом представлять большинство голосов на собраниях совета директоров или аналогичного органа управления (см. «Признаки контроля над компанией»).

Полная консолидация — это сведение финансовой отчетности всех компаний группы в одну. Это достигается построчным суммированием соответствующих показателей отчетных форм. То есть, показатели дочерней компании прибавляются к показателям материнской в полной сумме, даже если последней принадлежит менее 100 процентов голосующих акций «дочки».

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

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

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

Признаки существенного влияния:

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

Долевой метод учета обычно применяется в отношении ассоциированных компаний. Данные включают в виде показателей «Инвестиции в дочерние компании» и «Инвестиции в ассоциированные компании» в сводном балансе.

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

Совместные компании: пропорциональная консолидация

Одной из специфических форм объединения финансовых и иных ресурсов является создание совместных компаний. Или, что более характерно для России, заключение договора о совместной деятельности.

Понятие «совместная компания» содержится в МСФО 31 «Финансовая отчетность об участии в совместной деятельности». В соответствии с ним к любой схеме совместной деятельности применяется термин «совместная компания».

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

Как указано в МСФО 31, для учета и составления отчетности выделяют три типа совместного контроля:

• совместно контролируемые операции;
• совместно контролируемые активы;
• совместно контролируемые компании.

Рассмотрим особенности каждого из типов совместных предприятий.

Совместно контролируемые операции

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

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

Пример 1

Компании «Судоверфь 1» и «Судоверфь 2» заключают соглашение об учреждении совместной компании по строительству танкера. Компания «Судоверфь 1» осуществляет строительство конструкции корабля. Компания «Судоверфь 2» производит полное оснащение морского судна. В договоре о совместной деятельности предусмотрено, в каком соотношении компании делят доходы от продажи корабля и расходы, связанные с его строительством.

— Конец примера —

Совместно контролируемые активы

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

Совместно контролируемые компании

Совместная компания предполагает учреждение товарищества или предприятия иной организационно-правовой структуры, в которой каждый участник имеет свою долю участия.

Отличие подобной компании от остальных предприятий заключается в том, что на основании договора о совместной деятельности участники устанавливают контроль над всей работой организации. Достаточно часто подобные компании не ставят в качестве цели получение прибыли. Руководство такой организации действует не на основании Устава или иного аналогичного документа, а на основании доверенности, выданной ее участниками.

В § 19-24 МСФО 31 в качестве примера подобной компании рассмотрена такая ситуация. Предприятие начинает работу в другой стране или другом административном образовании на территории своей страны. При этом оно создает с местными органами власти или коммерческими структурами, действующими на территории данного государства или административного образования, совместное предприятие.

Пример 2

На основе договора о совместной деятельности компаниями «Регионсвязь», «Современные технологии» и администрацией Р-ской области учреждено простое товарищество «Р-связь». Договор устанавливает совместный контроль участников над экономической деятельностью компании «Р-связь». Компания «Р-связь» принимает обязательства, несет расходы, получает прибыль, от своего имени заключает договоры. Кроме того, она ведет бухгалтерский учет и составляет отчетность от своего имени. Каждый из участников сделал вложения в совместную компанию «Р-связь» либо в виде основных средств, нематериальных активов, материалов, либо в виде денежных средств. Каждый участник имеет право на часть результатов деятельности компании «Р-связь» в зависимости от условий, предусмотренных договором об учреждении простого товарищества.

— Конец примера —

Признаки контроля над компанией

Контроль права на голосование

1. Компания А покупает 60 процентов компании В и, соответственно, получает право на 60 процентов голосов на собрании акционеров. Компании А обладает контролем, несмотря на то, что 40 процентов голосов находятся в руках другой компании.

2. Компания А владеет 100 процентами предприятия оборонной сферы. Правительство назначает директоров предприятия. В данном случае компания А не обладает контролем, поскольку директора, назначенные правительством, могут не позволить проводить ее политику управления предприятием.

Получение контроля благодаря соглашению

Компания В покупает 40 процентов акций с правом голоса иностранной компании. Другие акционеры, владеющие 35 процентов ее акций, намерены предоставить фирме В право управлять их инвестициями на основе соглашения. В соответствии с этим документом фирма В получает голоса акционеров. В данном случае она получает контроль над компанией.

Контроль на основании законодательного акта

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

Контроль голосов

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

Мнение

Состав группы «по собственному усмотрению»

Ирина Горячева, старший аудитор Группы компаний «Градиент Альфа»:

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

Мнение

«Каждый из методов консолидации имеет свои плюсы и минусы»

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

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

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

— А затем данные бухгалтерских программ каждого предприятия просто сводятся воедино в центральном офисе?

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

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

— Однако некоторые компании применяют другой способ — так называемый метод консолидационных таблиц. В чем он заключается?

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

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

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

— Может ли каждое предприятие группы самостоятельно формировать собственную отчетность по МСФО?

— Безусловно. Именно такой подход используют при третьем методе. Готовые отчеты финансовые службы предприятий передают в головную компанию. Ее сотрудники суммируют полученные данные и делают консолидационные корректировки.

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

— Так какой же метод выбрать?

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

Что такое периметр консолидации?

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

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

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

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

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

Признаки существенного влияния:

• представительство в совете директоров или в ином органе управления;
• участие в процессе принятия управленческих решений в компании;
• наличие существенных операций между компанией-инвестором и компанией — объектом инвестирования;
• обмен сотрудниками руководящего звена между контролируемой и контролирующей компаниями;
• обмен важной технической информацией между контролируемой и контролирующей компаниями.

Долевой метод учета обычно применяется в отношении ассоциированных компаний. Данные включают в виде показателей «Инвестиции в дочерние компании» и «Инвестиции в ассоциированные компании» в сводном балансе.

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

Примечание. Признаки контроля над компанией

Контроль права на голосование

1. Компания А покупает 60 процентов компании В и соответственно получает право на 60 процентов голосов на собрании акционеров. Компания А обладает контролем, несмотря на то, что 40 процентов голосов находится в руках другой компании.
2. Компания А владеет 100 процентами предприятия оборонной сферы. Правительство назначает директоров предприятия. В данном случае компания А не обладает контролем, поскольку директора, назначенные правительством, могут не позволить проводить ее политику управления предприятием.

Получение контроля благодаря соглашению

Компания В покупает 40 процентов акций с правом голоса иностранной компании. Другие акционеры, владеющие 35 процентами ее акций, намерены предоставить фирме В право управлять их инвестициями на основе соглашения. В соответствии с этим документом фирма В получает голоса акционеров. В данном случае она получает контроль над компанией.

Контроль на основании законодательного акта

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

Контроль голосов

Компания К приобретает 20 процентов акций предприятия. Структура его капитала обеспечивает фирме К 60 процентов голосов на собраниях акционеров. Компания К обладает контролем, несмотря на то, что 80 процентов акций находится в руках других акционеров. Например, оставшиеся акции «размыты» между большим числом частных инвесторов, поэтому 20 процентов акций вполне достаточно для осуществления контроля над компанией.

Совместно контролируемые активы

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

Примечание. Состав группы «по собственному усмотрению»

Ирина Горячева, старший аудитор Группы компаний «Градиент Альфа»:

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

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

C. В. Манько, к. э. н., АССА, генеральный директор
ООО «Центр Методического Сопровождения Финансовой Отчетности»

Источник: Журнал «Корпоративная финансовая отчетность. Международные стандарты» № 7/2012

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

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

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

Справочно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Справочно

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

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

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

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.

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

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

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

Справочно

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

Реклассификационные корректировки выполняются путем переноса остатков и оборотов со счетов РСБУ на счета МСФО по правилам мэппинга5.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ПС МСФО.

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

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

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

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

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

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

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

• Консолидационные корректировки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критерий	Автоматизация метода трансформации	Автоматизация метода трансляции
Точность данных	Менее точные данные, корректировки рассчитываются и выполняются по состоянию на отчетную дату (за отчетный период)	Более точные и прозрачные данные (так как ведется учет каждой операции, а не перекладка остатков и оборотов)
Степень агрегирования данных	В основном использование агрегированных показателей, без детализации. По существенным операциям требуется дополнительный анализ	Пообъектный, поэлементный учет
Проверяемость данных (аудиторский след)	Переход до уровня первичного документа не поддерживается, так как обрабатываются агрегированные остатки и обороты, а не проводки. Если бухгалтерский учет ведется в одной базе, а трансформация и консолидация выполняются в другой, то требуется проверка загрузки/выгрузки данных.Физически разделены источник данных для трансформации (БУ) и механизмы трансформации	По каждой операции можно увидеть, как она отражена в бухгалтерском учете и учете по МСФО. Из каждой проводки МСФО можно перейти в документ-регистратор — документ МСФО или документ БУ, на основе которого сформирована проводка МСФО
Оперативность формирования данных	Требуется дождаться закрытия периода в БУ, после чего приступить к трансформации данных	Возможность формировать и анализировать данные МСФО в системе по мере необходимости. Большая часть проводок МФСО формируется в режиме онлайн при проведении документов БУ
Изменение данных МСФО при изменении данных в БУ	При изменениях в данных БУ требуется заново выгрузить данные для трансформации, если трансформация осуществляется во внешней системе (автоматический пересчет не выполняется)	При изменении данных в БУ изменения автоматически отражаются в МСФО по заданным правилам. Не требуются выгрузки данных во внешние системы, учет по БУ и МСФО ведется в едином программном продукте
Поддержка учета и отчетности в разных валютах	Выполняется пересчет данных по курсу на дату закрытия и среднему курсу за период. По существенным операциям требуются ручной анализ и пересчет по историческим курсам	Выполняется пересчет по точечным курсам на конкретную дату. Вмешательство в ручном режиме не требуется
Количество ручного труда при работе с системой	Требуются проверка корректности перегрузки данных и проверка работы алгоритмов трансформации и консолидации. По неавтоматизированным корректировкам требуются ручные расчеты. Если трансформация и консолидация организованы в отдельной базе, то специалистов по МСФО будет требоваться меньше, чем при ведении учета по МСФО в каждой компании.	Количество ручного труда зависит от степени автоматизации учета. Трансляция выполняется автоматически по правилам мэппинга. За любой период формируется отчет о результатах трансляции, в котором можно увидеть несконвертированные проводки или проводки, сконвертированные с ошибками. При детальной степени автоматизации задача по формированию МСФО сводится к последовательному выполнению ряда автоматизированных операций
Методологическое обеспечение	Требуется разработка/адаптация методологии по выполнению трансформационных и консолидационных корректировок	Требуется разработка/адаптация методологии по ведению учета и формированию отчетности по МСФО в программном продукте
Взаимосвязь с другими системами (кроме БУ)	—	Возможность организовать бюджетирование и управленческий учет с использованием информации в учете по МСФО
Связь с функционалом по консолидации	Выполняется трансформация данных бухгалтерского учета, в котором может отсутствовать весомая часть информации, требуемой для трансформации и консолидации МСФО. Этот объем потребует обработки в ручном режиме	В функционал по ведению учета по МСФО можно заложить возможности по упрощению дальнейшей консолидации (на уровне ПС, признаков контрагентов, выделения внутригрупповых продаж и пр.). Консолидировать отчетность даже вручную, имея учет по МСФО, гораздо проще, чем сначала сделать трансформацию данных БУ, а потом консолидацию
Зависимость от вышестоящих организаций, последствия изменения учетных политик	При изменении учетной политики, а также форматов выгрузки/загрузки данных потребуется изменение механизмов трансформации и консолидации. Технологически сложнее обеспечить сопоставимость сравнительных данных между периодами	Независимость от технической организации процесса подготовки данных по МСФО вышестоящими организациями (возможность автономного формирования отчетности по МСФО независимо от материнской компании согласно собственной методологии). Гибкость в вопросах выгрузки данных для вышестоящих организаций в любых форматах и разрезах. Подсистему МСФО проще адаптировать к новой учетной политике, автоматизировав операции по пересчету сопоставимых данных
Сроки внедрения	Сроки реализации короче (примерно в 1,5 раза по сравнению со вторым способом)	Больше сроки реализации
Стоимость внедрения	Стоимость внедрения ниже по сравнению со вторым способом	Выше стоимость внедрения
Сопровождение системы	Проще, дешевле, так как функционал проще и может быть сосредоточен в отдельном программном продукте (без установки в базу каждой компании)	Требуется полноценное сопровождение на уровне каждой компании. При изменениях в функционале БУ необходимо проводить мониторинг влияния изменений на блок МСФО

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

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

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

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

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

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

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

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

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

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

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

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

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

Маппинг данных

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

Итак, когда Вы создаете переменную, для нее выделяется место в памяти по определенному адресу (например ниже, с помощью дебагера в IDE, видно шестнадцатеричное число: 0x1c5e9d80, это и есть адрес в памяти).

А на этом скриншоте видны адреса всех переменных:

Когда вы создаете переменную (значение), приложение запрашивает у ОС место в куче. Наличие 32-битных адресов означает, что один экземпляр вашей программы не может использовать более 4 ГБ памяти. Два экземпляра одной программы могут выделить два разных сегмента физического адреса внутри одного сегмента виртуального адреса (0x00000000 в 0xffffffff).

Современные ОС используют виртуальное адресное пространство (ВАП, virtual address space) и процесс может работать с ячейками памяти по любым виртуальным адресам этого пространства, не «задумываясь» о том, где реально хранятся данные. Размер виртуальной памяти теоретически ограничивается разрядностью операционной системы. На практике в конкретной реализации операционной системы устанавливаются ограничения ниже теоретического предела.

В 32-разрядных системах (x86) используют для адресации 32 разрядные регистры (блоки ячеек памяти) и переменные, теоретический максимум составляет 4 ГБ (232 байт = 4 294 967 296 байт = 4 ГБ). Однако для процессов доступна только половина этой памяти – 2 ГБ , другая половина отдается системным компонентам.

В 64 разрядных системах (x64) теоретический предел равен 16 экзабайт (264 байт = 16 777 216 ТБ = 16 ЭБ). При этом процессам выделяется 8 ТБ, ещё столько же отдается системе, остальное адресное пространство (например в нынешних версиях Windows) не используется.

Реализация виртуальной памяти

Как уже отмечалось, процессу предоставляется виртуальное адресное пространство размером 4 ГБ. В Windows 2 ГБ расположенные по младшим адресам (0000 0000 – 7FFF FFFF), процесс может использовать по своему усмотрению (пользовательское ВАП), а оставшиеся два гигабайта (8000 0000 – FFFF FFFF) выделяются под системные структуры данных и компоненты (системное ВАП). Отметим, что каждый процесс имеет свое собственное пользовательское ВАП, а системное ВАП для всех процессов одно и то же.

В Linux i386 немного другие пропорции:

Виртуальные страницы

Виртуальная память делится на блоки одинакового размера – виртуальные страницы. В Windows страницы бывают большие (x86 – 4 МБ, x64 – 2 МБ) и малые (4 КБ). Физическая память (ОЗУ) также делится на страницы точно такого же размера, как и виртуальная память. Общее количество малых виртуальных страниц процесса в 32 разрядных системах равно 1 048 576 (4 ГБ / 4 КБ = 1 048 576).

Обычно процессы задействуют не весь объем виртуальной памяти, а только небольшую его часть. Соответственно, не имеет смысла (и, часто, возможности) выделять страницу в физической памяти для каждой виртуальной страницы всех процессов. Вместо этого в ОЗУ (говорят, «резидентно») находится ограниченное количество страниц, которые непосредственно необходимы процессу. Такое подмножество виртуальных страниц процесса, расположенных в физической памяти, называется рабочим набором процесса (working set).

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

Каким образом процесс узнает, где в данный момент находится требуемая страница? Для этого служат специальные структуры данных – таблицы страниц (page table).

Рассмотрим, из каких элементов состоит ВАП процесса

При запуске программы создается процесс, при этом в память загружаются:

• код программы
• данные программы
• необходимые программе динамически подключаемые библиотеки (DLL)

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

Для хранения информации о зарезервированных виртуальных страницах памяти используются дескрипторы виртуальных адресов (Virtual Address Descriptors, VAD). Каждый дескриптор содержит данные об одной зарезервированной области памяти и описывается структурой MMVAD.

Границы области определяются двумя полями – StartingVpn (начальный VPN) и EndingVpn (конечный VPN). VPN (Virtual Page Number) – это номер виртуальной страницы; страницы просто нумеруются, начиная с нулевой. Если размер страницы 4 КБ (212 байт), то VPN получается из виртуального адреса начала страницы отбрасыванием младших 12 бит (или 3 шестнадцатеричных цифр). Например, если виртуальная страница начинается с адреса 0x340000, то VPN такой страницы равен 0x340.

Дескрипторы виртуальных адресов для каждого процесса организованы в сбалансированное двоичное АВЛ дерево (AVL tree). Для этого в структуре MMVAD имеются поля указатели на левого и правого потомков: LeftChild и RightChild.

Трансляция адресов

В системе для каждого процесса поддерживается множество записей о страницах: если размер страницы 4 КБ, то чтобы хранить информацию обо всех виртуальных страницах в 32 разрядной системе требуется более миллиона записей (4 ГБ / 4 КБ = 1 048 576). Эти записи о страницах сгруппированы в таблицы страниц (Page Table), запись называется PTE (Page Table Entry). В каждой таблице содержится 1024 записи, таким образом, максимальное количество таблиц страниц для процесса – 1024 (1 048 576 / 1024 = 1024). В Windows половина от общего количества – 512 таблиц – отвечают за пользовательское ВАП, другая половина – за системное ВАП.

Таблицы страниц хранятся в виртуальной памяти (см. рис.11.2). Информация о расположении каждой из таблиц страниц находится в каталоге страниц (Page Directory), единственном для процесса. Записи этого каталога называются PDE (Page Directory Entry). Таким образом, процесс трансляции является двухступенчатым: сначала по виртуальному адресу определяется запись PDE в каталоге страниц, затем по этой записи находится соответствующая таблица страниц, запись PTE которой указывает на требуемую страницу в физической памяти.

Откуда процесс знает, где в памяти хранится каталог страниц? За это отвечает поле DirectoryTableBase структуры KPROCESS

Если опустить KPROCESS, то схема будет выглядеть немного проще:

Очень важно: синхронизация между виртуальными и физическими страницами памяти поддерживается аппаратно на уровне процессора, и называется трансляцией адресов. Данная технология «на лету» преобразует виртуальный адрес в физический и обратно.