Мэппинг счетов

Содержание

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

12.01.2016

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

Подготовительный этап трансформации отчетности

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

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

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

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

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

Мэппинг плана счетов для трансформации отчетности

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

Таблица 1. Пример мэппинга плана счетов

Несколько слов о составлении собственно плана счетов по МСФО.

  • Каждый показатель МСФО должен обладать уникальным цифровым кодом, в крайнем случае буквенно-цифровым, строго определенного формата. Суммирование показателей в современных версиях Excel возможно даже по текстовым признакам, однако в таком случае возрастает риск искажения данных в случае простой опечатки. Для сведения ошибок к минимуму применяются справочники и выпадающие списки с кодами и наименованиями счетов и аналитик, а также формулы «СУММЕСЛИ» и «ВПР», суммирующие данные с заданными признаками, а именно уникальными кодами.
  • Иерархия плана счетов должна позволять группировать данные не только по элементам, но также по строкам отчетной формы и примечаниям. Допустим, статья «Здания и сооружения — Первоначальная стоимость» помимо собственного кода должна также содержать среди аналитик код строки отчета о финансовом положении (далее по тексту — баланс) и код таблицы примечаний, что позволит заполнять формы и табличные примечания отчетности с помощью формул Excel.
  • Каждый раздел форм отчетности в плане счетов должен содержать запасные пустые строки — это дает возможность гибко корректировать план счетов без перенастройки формул, а также позволяет не нарушить принцип сопоставимости данных. Целесообразно предусмотреть место и для новых разделов, например, если компания ранее не имела инвестиционной собственности, но руководство планирует создание или приобретение недвижимого имущества для сдачи в аренду. В таком случае просто заполняются свободные строки и проставляются коды отчетности, а Excel автоматически агрегирует показатели.
  • Необходимо сохранять историю внесения изменений в мэппинг (как правило, на основании меморандума или иного распорядительного методологического документа) с указанием причины, ответственного лица, сроков вступления изменений в силу. Это важно как для формирования сопоставимых данных из периода в период, так и для прохождения аудита.

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

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

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

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

Таблица 2. Примерный перечень дополнительной информации

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

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

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

Таблица 3. Пример реклассификационной таблицы

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

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

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

Таблица 4. Расчет корректировки по дооценке основных средств по справедливой стоимости

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

Положения стандарта МСФО (IAS) 36 «Обесценение активов» также в большей степени направлены на тестирование основных средств и нематериальных активов, чья стоимость должна корректироваться при наличии признаков обесценения.

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

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

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

Среди наиболее часто встречающихся корректировок можно также отметить:

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

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

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

Таблица 5. Формирование списка входящих корректировок

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

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

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

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

Этап формирования корректировок для последующих отчетных периодов. Типовые корректировки в следующих отчетных периодах необходимо составлять с учетом входящих корректировок. Механизм формирования данных МСФО заключается в следующем — в таблицах Excel заполняются постранично:

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

Затем с помощью формул «СУММЕСЛИ» подтягиваются данные на сводный лист (см. таблицу 6).

Таблица 6. Формирование данных МСФО в трансформационной модели

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

Таблица 7. Пример использования функции Excel «СУММЕСЛИ»

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

Актуальная бухгалтерия

Подписка Разместить:

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

Насколько необходимо такое дорогостоящее «мероприятие»? Какую материальную выгоду можно извлечь в результате его проведения? В чем заключаются отличия системы российского бухгалтерского учета и финансовой отчетности от международных стандартов?

Параллельное ведение бухгалтерского учета: причины и требования

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

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

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

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

Особенности ведения бухгалтерского учета по IAS и российским ПБУ.

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

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

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

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

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

1. Западные нормативные акты в основном относятся к публичной отчетности, а в российском законодательстве расписаны сами методы ведения первичного учета;

2. На Западе нормативные акты по бухгалтерскому учету и отчетности могут не совпадать с налоговым законодательством, что обусловливает некоторое отличие результатов в бухгалтерском и налоговом учете.

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

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

1. Детализированный пересчет данных по каждой операции. Учет по двум стандартам можно вести по мере совершения сделки либо еженедельно, ежемесячно или ежеквартально. Это зависит от степени точности, установленной инвестором, а также от степени детализации отчетности, необходимой инвестору;

2. Пересчет только сальдо по счетам. Согласно данному методу необходимо вносить больше корректировок для устранения различий;

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

Некоторые различия между российскими положениями по бухгалтерскому учету и международными стандартами удалось преодолеть за счет автоматизированного учета по двум стандартам. Однако, как показывает опыт, систему учета по двум стандартам можно автоматизировать лишь на 90 %, а оставшиеся 10 % приходится исправлять вручную (следует отметить, что данное соотношение зависит от объема операций, и иногда оно меняется даже в сторону повышения доли автоматизированного учета).

К требованиям, позволяющим вести учет по двум стандартам в рамках единой системы ПО, относятся:

1. Возможность работы с необходимым количеством баз данных (на стадии внедрения ПО можно создавать отдельные базы данных по российским и международным стандартам, а также систему их взаимоотношений);

2. Аналитические коды, позволяющие проводить анализ счетов и операций.

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

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

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

5. Комплект отчетности по российским стандартам. Внешнее устройство по автоматическому составлению отчетности должно содержать встроенные формы всех отчетов в соответствии с требованиями российских налоговых и прочих нормативных актов.

Подходы к трансформации финансовой отчетности

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

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

Основные аспекты использования методики трансформации

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

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

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

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

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

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

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

2 этап. Анализ подготовленной учетной информации на полноту и соответствие требованиям российских ПБУ.

3 этап. Подготовка финансовой отчетности в соответствии с международными стандартами.

Для того чтобы подготовить финансовую отчетность в соответствии с IAS, необходимо:

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

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

3) составить отчетность в долларах США или иной иностранной валюте согласно требованиям IAS, с тем чтобы получить финансовую отчетность в твердой валюте;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wall Street Journal, например, дает такой совет: «Ищите консультанта по компьютерам, который вам подходит. Избегайте тех, кто начинает с обсуждения решений. Избегайте тех, кто проявляет особую склонность к определенным видам аппаратного и программного обеспечения. Избегайте консультантов, которые не могут объяснить, что делают, потому что это слишком сложно с технической точки зрения». На первый взгляд, более логичным может показаться первоначальный выбор компьютерной системы, а затем уже ПО. В действительности же лучше начать с приобретения последнего, тем более что в банке всегда имеется какое-то количество компьютеров. Как показывает практика, правильный выбор программного обеспечения наиболее важен для успеха работы компьютерной системы.

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

По мнению менеджера банка Bank of America Джона Холидея, компьютер хорош настолько, насколько хорошо его программное обеспечение.

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

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

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

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

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

Что такое маппирование данных и где это используется

Представим, что в одной из корпоративных систем сведения о семейном положении сотрудника хранятся так, что «1» в поле «дети» означает их наличие. В другой системе эти же данные записаны с помощью значения «True», а в третьей – словом «да». Таким образом, разные системы для обозначения одних и тех же данных используют разные отображения. Чтобы привести информацию к единообразию, следует сопоставить обозначения одной системы обозначениям в других источниках, т.е. выполнить процедуру мэппинга данных (от английского map – сопоставление). В широком смысле маппирование – это определение соответствия данных между разными семантиками или представлениями одного объекта в разных источниках. На практике этот термин чаще всего используется для перевода или перекодировки значений .

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

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

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

С прикладной точки зрения можно следующие приложения маппинга данных :

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

В Big Data мэппинг выполняется при загрузке информации в озеро данных (Data Lake) и корпоративное хранилище (DWH, Data Warehouse). Чем Data Lake отличается от DWH, рассмотрено . В этом случае маппинг реализуется в рамках ETL-процесса (Extract, Transform, Load) на этапе преобразования. При этом настраивается соответствие исходных данных с целевой моделью (рис. 1). В случае реляционных СУБД для идентификации одной сущности в разных представлениях нужно с ключами таблиц и настройкой отношений (1:1, *:1, 1:* или *:*) .

Рис.1. Маппирование данных при консолидации таблиц

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

Особенности процесса дата мэппинга

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

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

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

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

При работе с большими объемами данных выделяют 3 основных подхода к маппированию :

  • ручное кодирование, когда приходится писать код для консолидации данных из разных таблиц или форматов. Сюда же можно отнести сопоставление данных в графическом режиме, когда GUI специализированных программ позволяет пользователю рисовать линии от полей в одном наборе данных до соединения с другим источником. При этом «под капотом» автоматически генерируется программный код преобразования на SQL, XSLT, Java, C++ и прочих языках программирования. Такие графические средства часто встречаются в ETL-инструментах в качестве основного средства задания мэппингов для перемещения данных. Например, SAP BODS, Informatica PowerCenter и Talend Data Fabric (рис. 2).

Рис. 2. Маппирование в Talend Data Fabric

  • data-driven мэппинг, который сочетает оценку фактических значений данных в разных источниках данных с использованием эвристики и статистики для автоматического обнаружения сложных взаимосвязей между ними. Этот интеллектуальный подход используется для поиска преобразований между разными датасетами, выявления подстрок, конкатенаций, математический зависимостей, условных операторов и прочих логический преобразований. Также он позволяет найти исключения, которые не соответствуют обнаруженной логике преобразования. Обычно именно этот подход используется в специализированных системах подготовки данных к ML-моделированию, например, SAS, IBM SPSS и т.д.
  • семантический маппинг похож на вышеописанный data-driven метод, но здесь к интеллектуальному сопоставлению также подключается реестр метаданных. Например, если в исходной системе указано FirstName, а в системе-приемнике есть поле PersonGivenName, сопоставление будет успешно выполнено, если эти элементы данных перечислены как синонимы в реестре метаданных. Семантическое сопоставление способно выявить только точные совпадения между столбцами данных, но не обнаружит никакой логики преобразования или исключений между столбцами. На практике этот подход применяется при интеграции реляционных СУБД и построении DWH.

Также стоит упомянуть полуавтоматическое маппирование в виде конвертирования схем данных, когда специализированная программа сравнивает источники данных и целевую схему для консолидации. Затем разработчик проверяет схему маппирования и вносит исправления, где это необходимо. Далее программа конвертирования схем данных автоматически генерирует код на C++, C # или Java для загрузки данных в систему приемник (рис. 3) .

Рис. 3. Конвертирование схем данных в процессе мэппинга

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

Инструменты маппирования больших данных

Как и большинство прикладных решений, все средства для маппинга данных можно разделить на 3 категории :

  • проприетарные (on-premise), например, Centerprise Data Integrator, CloverDX, IBM InfoSphere, Informatica PowerCenter, Talend Data Integration. Как правило, эти продукты широко используются в корпоративном секторе.
  • открытые (open-source), которые дешевле предыдущих аналогов и являются более легковесными с точки зрения функциональных возможностей. Однако их вполне достаточно для индивидуальных исследований Data Science. Наиболее популярными в этой категории считаются Pentaho, Pimcore, Talend Open Studio.
  • облачные сервисы, такие как, Informatica Cloud Data Integration, Oracle Integration Cloud Service, Talend Cloud Integration, Dell Boomi AtomSphere, DX Mapper, Alooma, Jitterbit. Современные Cloud-решения считаются безопасными, быстрыми, масштабируемыми, относительно недорогими и удобными для использования. Поэтому их можно применять как в корпоративных, так и в личных целях.

Большинство перечисленных продуктов поддерживают все 3 подхода к маппированию: ручной (GUI и кодирование), data-driven и семантический. Однако, семантический мэппинг требует наличия реестров метаданных, что имеется далеко не в каждом предприятии. А публичные реестры метаданных, такие как национальные, отраслевые или городские репозитории не всегда напрямую коррелируют, например, с задачами построения локального DWH. Но, наряду с открытыми государственными данными и другими публичными датасетами, их можно использовать в исследовательских DS-задачах.

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

  • cложность данных – объемы, разнообразие форматов и схем. Этот критерий непосредственно связан со спецификой задачи. Например, если требуется обогатить не слишком большой датасет для ML-моделирования, сопоставив данные из нескольких источников, Data Scientist может воспользоваться простым облачным сервисом или написать собственный скрипт. Однако, в случае регулярной загрузки информации из множества СУБД в корпоративное хранилище или озеро данных, необходимо выбирать надежное ETL-средство enterprise-уровня.
  • расширяемость – наглядный GUI повышает удобство пользования, однако, на практике часто возникает задача кастомизации автоматически сгенерированных соответствий. Поэтому инструмент маппирования должен включать возможность править созданные мэппинги, настраивать правила и писать собственные преобразования в виде программных скриптов.
  • стоимость, включая все затраты на приобретение, использование, техническую поддержку и прочие расходы.

Резюме

Итак, маппирование данных – это важная часть процесса работы с данными, в том числе и для Data Scientist’а. Эта процедура выполняется в рамках подготовки к ML-моделированию, в частности, при обогащении датасетов. В случае одноразового формирования датасета из нескольких разных источников сопоставление данных можно выполнить вручную или с помощью самописного Python-скрипта. Однако, такой подход не применим в промышленной интеграции нескольких информационных систем или построении корпоративных хранилищ и озер данных. Поэтому знание инструментов дата мэппинга пригодится как Data Scientist’у, так и Data Engineer’у. Наконец, сопоставление данных с целью избавления от дублирующихся и противоречивых значений входит в задачи обеспечения качества данных (Data Quality) . В свою очередь, Data Quality относится к области ответственности стратега по данным и инженера по качеству данных. Таким образом, понимание процесса маппирования необходимо каждому Data-специалисту.

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

Параллельный учет и трансформация отчетности.

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

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

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

1. Метод параллельного учета

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

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

2. Метод трансформации отчетности МСФО

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

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

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

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

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

Начать работу (обычно в электронных таблицах Excel) рекомендуется с составления рабочей таблицы входящих остатков. Для этого необходимо перенести, а затем перегруппировать и реклассифицировать информацию из отчетности РСБУ (баланс, ОПУ) в таблицу входящих остатков. На практике во избежание недоразумений со знаками всех сумм они соответствуют логике бухгалтерских проводок: активы заносятся в трансформационную таблицу со знаком плюс, а обязательства и капитал со знаком минус. Перегруппировка означает, что заносить остатки нужно с учетом их будущей презентации в балансе по МСФО. Трансформационная таблица заполняется и по строкам, и столбцам: по строкам показываются наименования статей баланса и отчета о прибылях и убытках по МСФО, а по столбцам – остатки по российским данным. Затем заносятся все индивидуальные корректировки по МСФО и в результате – выводимые на их основе остатки отчетности по МСФО.
Один из основных недостатков трансформации состоит в отсутствии возможности ведения параллельного учета и представления руководству компании и другим заинтересованным лицам необходимой информации на оперативной основе, т. е. в промежутке между отчетными датами.
В целом финансовая отчетность, полученная в результате трансформации, менее точна, и общий риск ошибок выше, чем при ведении параллельного учета. Погрешность составляет от 10% до 50%.Поскольку трансформация представляет собой упрощенный процесс, то при составлении отчетности в соответствии с МСФО используется много оценочных суждений. Например, если отчетность составляется в иностранной валюте, то при отсутствии параллельного учета невозможно точно определить курс для формирования исторической стоимости товарно-материальных ценностей. Определенная степень оценки должна применяться при элиминировании российской амортизации и других общепроизводственных расходов из себестоимости готовой и реализованной продукции и распределении амортизации и общепроизводственных расходов, начисленных по МСФО. Трансформация затрагивает исключительно статьи бухгалтерской отчетности, а параллельное ведение бухгалтерского учета обеспечивает формирование финансовой отчетности по МСФО на основе соответствующих бухгалтерских записей, сделанных в течение всего отчетного периода. Следовательно, трансформация предусматривает преобразование российской бухгалтерской отчетности в финансовую отчетность по МСФО только по состоянию на отчетную дату (конец отчетного года, квартала).

3. Сравнительный анализ методов параллельного учета и трансформации отчетности МСФО

Далее сравним оба метода, сведя для удобства и наглядности достоинства и недостатки каждого их них. (таблица 3.1.)

Таблица 3.1.
Сравнительная характеристика способов получения отчетности по МСФО

Признак

Параллельный учет

Трансформация отчетности

Достоверность отчетности

+ потенциально высокая степень надежности информации

– потенциально высокий информационный риск
– неизбежное присутствие субъективных оценок

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

– требует от компании существенных затрат

+ не требует от компании существенных затрат

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

– продолжительный, т.к. подразумевает «отладку» системы параллельного учета

+ непродолжительный

Оперативность составления отчетности

+ практически одновременно с составлением российской отчетности

– только после составления российской отчетности

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

Недостатками параллельного учета являются:

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

К недостаткам трансформации можно отнести следующее:

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

Заключение

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

Маппинг данных – один из способов для разделения кода приложения на слои. Маппинг широко используется в Android приложениях. Популярный пример архитектуры мобильного приложения Android-CleanArchitecture использует маппинг как в оригинальной версии (пример маппера из CleanArchitecture), так и в новой Kotlin версии (пример маппера).

Маппинг позволяет развязать слои приложения (например, отвязаться от API), упростить и сделать код более наглядным.

Пример полезного маппинга изображен на схеме:

Нет нужды передавать все поля модели Person, если в интересующей нас части приложения нам нужно только два поля: login и password. Если для нас удобнее рассматривать Person как пользователя приложения, после маппига мы можем легко использовать модель с понятным нам именем.

Рассмотрим удобные и практичные методы маппинга данных на примере преобразования двух моделей Person и Salary из слоя Source в модели слоя Destination.

Для примера модели упрощены. Person содержит Salary в обоих слоях приложения.

В настоящем коде, если у вас одинаковые модели, возможно, стоит пересмотреть слои приложения и не использовать маппинг.

Метод №1: Методы-мапперы

Пример:

class PersonSrc( private val name: String, private val salary: SalarySrc ) { fun mapToDestination() = PersonDst( name, salary.mapToDestination() // вызов маппера для Salary ) } class SalarySrc( private val amount: Int ) { fun mapToDestination() = SalaryDst(amount) }

Самый быстрый и простой метод. Именно он используется в CleanArchitecture Kotlin (пример маппинга).

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

Такой код быстрее писать и проще модифицировать – объявления полей и их использование находятся в одном месте. Не надо бегать по проекту и модифицировать разные файлы при изменении полей класса.

Однако, этот вариант сложнее тестировать. В методе-маппере класса PersonSrc прописан вызов метода-маппера SalarySrc. Значит протестировать маппинг только Person без маппинга Salary будет сложнее. Для этого придется использовать моки.

Еще проблема может возникнуть если по требованиям архитектуры слои приложения не могут знать друг о друге: т.е. в классе Src слоя нельзя работать со слоем Dst и наоборот. В этом случае такой вариант маппинга использовать не получится.

В рассмотренном примере слой Src зависим от слоя Dst и может создавать классы этого слоя. Для обратной ситуации (когда Dst зависим от Src) подойдет вариант со статическими методами-фабриками:

class PersonDst( private val name: String, private val salary: SalaryDst ) { companion object { fun fromSource( src: PersonSrc ) = PersonDst(src.name, SalaryDst.fromSource(src.salary)) } } class SalaryDst( private val amount: Int ) { companion object { fun fromSource(src: SalarySrc) = SalaryDst(src.amount) } }

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

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

Резюме метода маппинга:

+ Быстро писать код, маппинг всегда под рукой
+ Легкая модификация
+ Низкая связность кода
— Затруднено Unit-тестирование (нужны моки)
— Не всегда позволено архитектурой

Метод №2: функции-мапперы

Модели:

class PersonSrc( val name: String, val salary: SalarySrc ) class SalarySrc(val amount: Int) class PersonDst( val name: String, val salary: SalaryDst ) class SalaryDst(val amount: Int)

Мапперы:

fun mapPerson( src: PersonSrc, salaryMapper: (SalarySrc) -> SalaryDst = ::mapSalary // аргумент по-умолчанию ) = PersonDst( src.name, salaryMapper.invoke(src.salary) ) fun mapSalary(src: SalarySrc) = SalaryDst(src.amount)

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

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

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

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод № 3: Функции-расширения

Мапперы:

fun PersonSrc.toDestination( salaryMapper: (SalarySrc) -> SalaryDst = SalarySrc::toDestination ): PersonDst { return PersonDst(this.name, salaryMapper.invoke(this.salary)) } fun SalarySrc.toDestination(): SalaryDst { return SalaryDst(this.amount) }

В целом то же, что и функции-мапперы, но проще синтаксис вызова маппера: .toDestination().

При этом стоит учесть, что функции расширения могут приводить к неожиданному поведению из-за своей статической природы: https://kotlinlang.org/docs/reference/extensions.html#extensions-are-resolved-statically

Резюме метода маппинга:

+ Простое Unit-тестирование
— Затруднена модификация
— Требуются открытые поля у классов с данными

Метод №4: Классы-мапперы с интерфейсом

У примеров с функциями есть недостаток. Они позволяют в качестве маппера использовать любую функцию с сигнатурой (SalarySrc) -> SalaryDst. Сделать код более очевидным поможет наличие интерфейса Mapper<SRC, DST>.

Пример:

interface Mapper<SRC, DST> { fun transform(data: SRC): DST } class PersonMapper( private val salaryMapper: Mapper<SalarySrc, SalaryDst> ) : Mapper<PersonSrc, PersonDst> { override fun transform(src: PersonSrc) = PersonDst( src.name, salaryMapper.transform(src.salary) ) } class SalaryMapper : Mapper<SalarySrc, SalaryDst> { override fun transform(src: SalarrSrc) = SalaryDst( src.amount ) }

В данном примере SalaryMapper – зависимость PersonMapper. Это позволяет удобно подменять маппер Salary для unit-тестов.

Относительно маппинга в функции у этого примера только один недостаток – необходимость писать немного больше кода.

Резюме метода маппинга:

+ Лучше типизация
— Больше кода

Как и функции-мапперы:

+ Простое Unit-тестирование
— Затруднена модификация
— требует открытые поля у классов с данными

Метод 5: Рефлексия

Метод черной магии. Рассмотрим этот метод на других моделях.

Модели:

data class EmployeeSrc( val firstName: String, val lastName: String, val age: Int // много других полей ) data class EmployeeDst( val name: String, // одно поле, а не два val age: Int // много других полей )

Маппер:

fun EmployeeSrc.mapWithRef() = with(::EmployeeDst) { val propertiesByName = EmployeeSrc::class.memberProperties.associateBy { it.name } callBy(parameters.associateWith { parameter -> when (parameter.name) { EmployeeDst::name.name -> «$firstName $lastName» // маппит только поле name else -> propertiesByName?.get(this@mapWithRef) // остальные поля без изменений } }) }

Пример подсмотрен .

В данном примере EmployeeSrc и EmployeeDst хранят имя в разных форматах. Мапперу нужно только составить имя для новой модели. Остальные поля обработаются автоматически, без написания кода (вариант else в when).

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

Большая проблема возникнет, например, если вы добавите обязательные поля в Dst и его случайно не окажется в Src или в маппере: cлучится IllegalArgumentException в runtime. Также рефлексия имеет проблемы с производительностью.

Резюме метода маппинга:

+ меньше кода
+ простое Unit-тестирование
— опасен
— может негативно сказаться на производительности

Выводы

Такие выводы можно сделать из нашего рассмотрения:

Методы-мапперы — наглядный код, быстрее писать и поддерживать

Функции-мапперы и функции расширения – просто тестировать маппинг.

Классы мапперы с интерфейсом — просто тестировать маппинг и яснее код.

Рефлексия – подходит для нестандартных ситуаций.

Добавить комментарий

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