/НАЗАД
С момента принятия в 2002 году 25 главы НК РФ, большинство реализаций налогового учета в SAP были основаны на использовании модуля FI-SL «Специальные регистры», либо, после появления ERP 2004, на функциональности гибкой главной книги. Широко распространено «Типовое проектное решение» из Российской локализации SAP. Однако, часто встречаются и оригинальные решения. Например, автор около 10 лет назад участвовал в проекте, где требования налогового учета были полностью реализованы в модуле EC-CS, с отчетностью по МСФО и РСБУ параллельно. Однако, все решения, ограниченные рамками ERP системы, имеют одни те же «родовые травмы», связанные с принципиальной ограниченностью функциональности специальных регистров или являющейся их развитием гибкой главной книги. Естественным выходом из этой ситуации является перенос налоговой отчетности из ERP системы в BW. «Примером для подражания» может служить перенос специалистами компании SAP функционала консолидации финансовой отчетности из ERP (EC-CS) в BW (SEM-BCS) практически без изменений.
В настоящей статье описывается методология и принципы технической реализации требований 25 главы НК и ПБУ 18/02 в SAP BW. Использование возможностей OLAP отчетности позволяет удовлетворить всем требованиям законодательства, что принципиально невозможно при помощи такого примитивного генератора отчетов как Report Painter. Особенно, следует подчеркнуть, что использование инструментария BW даёт возможность бухгалтеру найти такие инструменты для проведения сверок и поиска ошибок в первичных документах, которые ERP отчетность не может дать ни при каких условиях. Гибкий и мощный механизм построения BW хранилищ данных позволяет свести воедино весь массив необходимой информации, не только из Главной книги, но из разных ERP модулей, например, «Контроллинга» и «Учета основных средств». Следует упомянуть, что это принципиально невозможно при использовании FI-SL.
Нельзя не коснуться такой темы как SAP HANA. Автор придерживается того, мнения, что использование BW on HANA – наиболее рациональный путь повышения отдачи от корпоративной системы аналитической и финансовой отчетности. Описываемое в статье решение основано на реализации в рамках «классического» BW. Однако, при его «миграции» на SAP HANA, никаких принципиальных изменений не потребуется. Можно, конечно, в качестве объектов хранения данных, заменить инфо-кубы на DSO, но это никак не скажется ни на общей архитектуре, ни на отдельных функциях описываемого ниже решения.
Архитектура решения и поддерживаемая им методология налогового учета
Выше было сказано, что «примером для подражания» может служить перенос функционала консолидации финансовой отчетности из EC-CS в SEM-BCS. Действительно, мотивация в обоих случаях полностью совпадает. Больше того, архитектура реализации НУ во многих принципиальных моментах неизбежно будет копировать принципы, на которых основывается SEM-BCS. Перечислим их:
- Разделение прикладной функциональности и «Базиса данных», с целью добиться максимальной независимости от деталей реализации хранилища исходных данных.
- Четкая формулировка поддерживаемой методологии учета, с заранее предусмотренными возможностями настройки и расширения. Исходя из этого, фиксируется набор аналитических признаков и показателей, составляющих модель данных НУ.
- Алгоритмы трансформации при переносе из Базиса данных в модель данных НУ должны быть максимально гибкими и, одновременно, строго «заточенными» под решаемую задачу.
- Система отчетности должна быть встроена в прикладную функциональность.
Все исходные данные первоначально сохраняются в таблицах ERP системы. Для налогового учета представляют интерес следующие SAP модули:
- FI-GL – Главная книга. На практике чаще всего встречается гибкая главная книга с выделенным «налоговым» регистром. Однако, это не является обязательным требованием.
- FI-AA – Учет ОС и НМА. Предполагается, что имеются следующие области оценки:
- оценка в соответствии с РСБУ;
- оценка в соответствии с требованиями 25 главы НК;
- постоянные налоговые разницы;
- налоговые разницы без постоянных разниц.
- FI-GL-ACE – Расходы и доходы будущих периодов (Accrual Engine). Использование данного модуля является опциональным. Иногда списание расходов будущих периодов настраивается в модуле учета ОС FI-AA.
- CO-OM – Контроллинг косвенных затрат. Перераспределение расходов внутри модуля СО-OM, как правило, приводит к изменению их классификации с точки зрения НУ. Кроме того, часто, непростой задачей является явное выделение капитализируемых расходов и НЗП.
Все необходимые данные импортируются из ERP в систему BW, где формируется корпоративное хранилище данных (КХД). КХД является основой для построения общей аналитической отчетности и, одновременно, служит базисом данных для Модуля НУ. Обычно, в соответствии с рекомендациями SAP, КХД строится на основе стандартного BW контента.
Здесь уместно сделать следующее замечание. Часто выделяются два основных подхода к ведению параллельного учета в SAP:
- Разделение видов учета при помощи выделения в общем плане счетов специальных «забалансовых» диапазонов.
- Разделение видов учета при помощи отдельных регистров в гибкой главной книге.
Поддерживаемая методология НУ
Конечным результатом решения является формирование отчетов, в соответствии с требованиями законодательства:
- Декларация по налогу на прибыль – имеет фиксированный формат, устанавливаемый законодательством. Отправляется в налоговые органы в виде XML файла, но должна иметь и обычное «бумажное» представление.
- Расчет налоговой базы ‑ сводный синтетический регистр расчета налога на прибыль, формируемый на основе аналитических регистров налогового учета, согласно статье 313 НК РФ.
- Аналитические регистры налогового учета ‑ обязательные отчетные формы, предусмотренные в статьях 313 и 314 НК РФ. Ниже, для краткости, они будут называться налоговыми регистрами. Их формат разрабатывается налогоплательщиком самостоятельно.
- Отчет о налоговых разницах – сводная отчетная форма. Показывает процесс начисления и списания постоянных и временных налоговых разниц в разрезе имеющихся в системе аналитических признаков. Одним из результатов отчета является определение базы для начислений и списаний отложенных налоговых активов и обязательств (ОНА/ОНО). Аналогично тому, как «Расчет налоговой базы» строится на данных налоговых регистров, «Отчет о налоговых разницах» строится на данных аналитических регистров разниц.
Как с методологической, так и с технической точек зрения, обязательным решением является введение промежуточного, между финальными отчетами и первичными документами, уровня хранения данных на котором происходит их налоговая классификация (присвоение номеров налоговых регистров и регистров разниц). Общая логическая структура потока данных проиллюстрирована на следующей схеме (Рис.1):
Рис.1. Логическая схема потока данных
Каждая строка Декларации формируется как простая сумма оборотов по одному или нескольким налоговым регистрам. Аналогично, «Отчет о налоговых разницах» строится на данных регистров разниц. Как Декларация, так и Отчет о разницах, являются виртуальными объектами. Уровень же регистров – это уровень хранения «вычищенных» и проклассифицированных данных, оптимизированный для решения конкретной задачи.
При переносе первичных документов из «Базиса Данных» в «Модуль НУ», происходит деривация номеров регистров. Правила деривации могут быть произвольного уровня сложности и использовать любую информацию, содержащуюся в первичных документах. Вместе с рассчитанным номером регистра сохраняются основные объекты контировок, например, номер счета, МВЗ, вид внутреннего заказа и т.п.
Согласно статье 313 НК РФ, подтверждением данных налогового учета являются первичные учетные документы (включая справку бухгалтера). В системе отдельные документы хранятся на уровне «Базиса данных» и в «Модуль НУ» не переносятся. Однако, всегда можно определить в какой регистр включен тот или иной первичный документ.
Согласно статье 313 НК РФ, подтверждением данных налогового учета являются первичные учетные документы (включая справку бухгалтера). В системе отдельные документы хранятся на уровне «Базиса данных» и в «Модуль НУ» не переносятся. Однако, всегда можно определить в какой регистр включен тот или иной первичный документ.
Технически, каждый регистр имеет уникальный номер и включен как объект самого нижнего уровня в следующую иерархию:
Рис.2. Иерархия налоговых регистров
Аналогично, для регистров разниц имеется следующая классификация:
Рис.3. Иерархия регистров разниц
Эта диаграмма показывает формат столбцов «Отчета о налоговых разницах». Его строки могут строиться как на иерархии налоговых регистров, так и на счетах РСБУ. Например, типичным требованием является «развертка» налоговых разниц по строкам Формы № 2. В целом, наличие полного набора требуемых аналитических признаков позволяет строить эффективные многомерные модели данных для OLAP отчетности.
Для целей налогового учета достаточно иметь единственный показатель – сумму оборотов в рублях. Временная гранулярность хранимых данных – финансовый период (месяц). При этом, следует иметь в виду, что год и период отнесения доходов и расходов в НУ и РСБУ могут не совпадать. Кроме того, особенности законодательства приводят к необходимости иметь в структуре данных дополнительную аналитику «Номер корректировки».
Деривация налоговых регистров и регистров разниц
Аналитические признаки налоговый регистр и негистр разниц, на которых строится вся налоговая отчетность, отсутствуют в первичных документах. При переносе информации из Базиса данных в Модуль НУ, происходит их деривация в два шага:
- номера регистров по умолчанию присваиваются бухгалтерским счетам и элементам затрат;
- окончательные номера регистров определяются при помощи настроенных в системе правил деривации.
Практика показывает, что реальные правила определения номеров регистров оказываются исключительно сложными. Во-первых, их много – каждая хозяйственная операция, для которой «не срабатывает» простой мэппинг на план счетов, порождает отдельное правило. Во-вторых, почти всегда в правилах присутствует ЕСЛИ-ТО логика, что делает процесс деривации ветвящимся. И, в третьих, в определении отдельных правил могут использоваться достаточно большие и меняющиеся со временем наборы объектов (например, номера счетов, ССП-элементов или внутренних заказов). Основная причина этих сложностей ‑ это, конечно, различие требований РСБУ и Налогового Кодекса. Но, часто, они бывают вызваны неисправимыми «огрехами» в настройках продуктивной системы, сделанными еще в процессе внедрения. Одним словом, это – тот самый случай, когда реальность оказывается сложнее «теории».
Деривация номеров регистров – ключевой узел всей системы. Если она не сможет заработать полностью автоматически, то претензия на формирование системой налоговой отчетности окажется несостоятельной, и бухгалтеру придется вернуться к привычной практике выгрузки промежуточных данных в Excel с их дальнейшей обработкой вручную.
Отчетность
Отчеты «Декларация по налогу на прибыль», «Расчет налоговой базы» и «Отчет о налоговых разницах» имеют фиксированный формат и служат, в числе прочего, «документарным» целям. Аналитические регистры налогового учета и регистры разниц являются реестрами первичных документов. Цифры в любом отчете должны быть проверяемыми. Поиск и исправление ошибок является едва ли не самой трудоемкой задачей, встающей перед бухгалтером в процессе повседневной работы. Для этой цели следует использовать такой мощный инструмент как OLAP отчетность в BW. Гибкие функции фильтрации данных и навигации позволяют решить задачи сверки и поиска ошибок оптимальным образом. Особенно полезна функция «проваливания» из отчета в отчет вплоть до первичного документа (drill-down).
Техническая реализация
Ниже описываются основные принципы технической реализации рассматриваемого решения. Следует сразу оговориться, что все её детали описать в одной статье невозможно. Поэтому целью автора является лишь дать читателю общее представление о том, как описанные выше (разделы?) требования могут быть адекватно реализованы при помощи инструментария SAP BW.
На следующей схеме (Рис. 4) изображены участвующие в процессе BW объекты и потоки данных между ними:
Рис. 4 Техническая схема потока данных.
Таблица 1. Объекты на схеме потока данных (Рис. 4).
При детальном описании потока данных, логично пойти снизу-вверх. Объекты, формирующие Базис данных, имеют прямые аналоги в стандартном SAP контенте (в простейшем случае, просто являются их копиями). Бухгалтерские документы из ERP реплицируются в DSO_04, результаты перераспределения косвенных расходов – в IC_03. Возможны ситуации, когда налоговые разницы возникают за счет проводок по разным счетам: начисления проводятся по одному счету, а списания – по другому счёту, отличному от первого. В DSO_01 подокументно сохраняется разность между такими начислениями и списаниями, то есть формируются сами разницы. DSO_05 хранит исходную информацию об амортизации ОС и НМА, а DSO_06 – о списании РБП. Для корректного расчета разниц необходимо анализировать данные из разных областей оценки. Это происходит в пользовательских программах трансформаций при переносе данных в DSO_02 и DSO_03. По сути, если бы задача была ограничена только расчетом базы налога на прибыль, то DSO_01, DSO_02 и DSO_03 были бы не нужны. Требование расчета налоговых разниц значительно усложняет всю техническую реализацию.
Инфо-источник IS_01 создает универсальный интерфейс для входящего потока данных для алгоритма деривации номеров регистров. Деривация происходит в программе запуска в трансформации из IS_01 в IC_01. Сам алгоритм требует гибкого инструмента настроек. Для реализации используется технология BRF+ (Business Rules Framework Plus), позволяющая задавать правила произвольного уровня сложности при помощи универсального графического интерфейса. Поскольку созданные правила автоматически компилируются в АВАР код, данный подход является оптимальным для использования внутри пользовательских программ в трансформациях. Инфо-куб IC_01 содержит все данные, необходимые для формирования отчетности по налогу на прибыль и налоговым разницам. Для расчетов при помощи функций планирования служит инфо-куб реального времени IC_02. В частности, в нем решается задача расчета налога на прибыль по обособленным подразделениям. На мульти-провайдерах MP_01 и MP_02 строится отчетность. Кроме того, MP_02 служит в качестве базового провайдера для уровней агрегации, реализующих BI-IP функции, такие как копирование налоговой базы и расчеты при помощи функций планирования.
Репорт-репорт интерфейсы создают потоки данных в обратном направлении, вплоть до первичных документов в ERP. При этом отчеты, участвующие в интерфейсах строятся на виртуальных инфо-провайдерах, являющихся своего рода оболочками над реальными DSO.
Что дальше?
Отчетности по налогу на прибыль, НДС и имущественным налогам тесно связаны. Например, корректировка декларации для одного из этих налогов автоматически требует корректировки и для другого налога. Формирование Декларации по НДС в BW является вполне естественным решением. А учитывая возможности, предоставляемые OLAP отчетностью для сверок и поиска ошибок, такое решение даст бухгалтеру мощные инструменты, которых он, по определению, лишен в ERP. Поскольку база данных об основных средствах уже создана в рамках автоматизации налога на прибыль, естественным решением является построение на ее основе отчетности по имущественным налогам.
Автор: Дмитрий Булатов
Кандидат физико-математических наук. Более 25 лет опыта внедрения информационных систем в различных отраслях экономики. Экспертные знания архитектуры платформ SAP ERP и SAP BI. Глубокое понимание предметных областей финансового и управленческого учета, бюджетирования и консолидации. Успешный опыт построения комплексных архитектур SAP BI и SAP ERP на российских и международных проектах. Эксперт в функциональностях SAP BW, FI, CO, FI-FM.
/НАЗАД
С момента принятия в 2002 году 25 главы НК РФ, большинство реализаций налогового учета в SAP были основаны на использовании модуля FI-SL «Специальные регистры», либо, после появления ERP 2004, на функциональности гибкой главной книги. Широко распространено «Типовое проектное решение» из Российской локализации SAP. Однако, часто встречаются и оригинальные решения. Например, автор около 10 лет назад участвовал в проекте, где требования налогового учета были полностью реализованы в модуле EC-CS, с отчетностью по МСФО и РСБУ параллельно. Однако, все решения, ограниченные рамками ERP системы, имеют одни те же «родовые травмы», связанные с принципиальной ограниченностью функциональности специальных регистров или являющейся их развитием гибкой главной книги. Естественным выходом из этой ситуации является перенос налоговой отчетности из ERP системы в BW. «Примером для подражания» может служить перенос специалистами компании SAP функционала консолидации финансовой отчетности из ERP (EC-CS) в BW (SEM-BCS) практически без изменений.
В настоящей статье описывается методология и принципы технической реализации требований 25 главы НК и ПБУ 18/02 в SAP BW. Использование возможностей OLAP отчетности позволяет удовлетворить всем требованиям законодательства, что принципиально невозможно при помощи такого примитивного генератора отчетов как Report Painter. Особенно, следует подчеркнуть, что использование инструментария BW даёт возможность бухгалтеру найти такие инструменты для проведения сверок и поиска ошибок в первичных документах, которые ERP отчетность не может дать ни при каких условиях. Гибкий и мощный механизм построения BW хранилищ данных позволяет свести воедино весь массив необходимой информации, не только из Главной книги, но из разных ERP модулей, например, «Контроллинга» и «Учета основных средств». Следует упомянуть, что это принципиально невозможно при использовании FI-SL.
Нельзя не коснуться такой темы как SAP HANA. Автор придерживается того, мнения, что использование BW on HANA – наиболее рациональный путь повышения отдачи от корпоративной системы аналитической и финансовой отчетности. Описываемое в статье решение основано на реализации в рамках «классического» BW. Однако, при его «миграции» на SAP HANA, никаких принципиальных изменений не потребуется. Можно, конечно, в качестве объектов хранения данных, заменить инфо-кубы на DSO, но это никак не скажется ни на общей архитектуре, ни на отдельных функциях описываемого ниже решения.
Архитектура решения и поддерживаемая им методология налогового учета
Выше было сказано, что «примером для подражания» может служить перенос функционала консолидации финансовой отчетности из EC-CS в SEM-BCS. Действительно, мотивация в обоих случаях полностью совпадает. Больше того, архитектура реализации НУ во многих принципиальных моментах неизбежно будет копировать принципы, на которых основывается SEM-BCS. Перечислим их:
- Разделение прикладной функциональности и «Базиса данных», с целью добиться максимальной независимости от деталей реализации хранилища исходных данных.
- Четкая формулировка поддерживаемой методологии учета, с заранее предусмотренными возможностями настройки и расширения. Исходя из этого, фиксируется набор аналитических признаков и показателей, составляющих модель данных НУ.
- Алгоритмы трансформации при переносе из Базиса данных в модель данных НУ должны быть максимально гибкими и, одновременно, строго «заточенными» под решаемую задачу.
- Система отчетности должна быть встроена в прикладную функциональность.
Все исходные данные первоначально сохраняются в таблицах ERP системы. Для налогового учета представляют интерес следующие SAP модули:
- FI-GL – Главная книга. На практике чаще всего встречается гибкая главная книга с выделенным «налоговым» регистром. Однако, это не является обязательным требованием.
- FI-AA – Учет ОС и НМА. Предполагается, что имеются следующие области оценки:
- оценка в соответствии с РСБУ;
- оценка в соответствии с требованиями 25 главы НК;
- постоянные налоговые разницы;
- налоговые разницы без постоянных разниц.
- FI-GL-ACE – Расходы и доходы будущих периодов (Accrual Engine). Использование данного модуля является опциональным. Иногда списание расходов будущих периодов настраивается в модуле учета ОС FI-AA.
- CO-OM – Контроллинг косвенных затрат. Перераспределение расходов внутри модуля СО-OM, как правило, приводит к изменению их классификации с точки зрения НУ. Кроме того, часто, непростой задачей является явное выделение капитализируемых расходов и НЗП.
Все необходимые данные импортируются из ERP в систему BW, где формируется корпоративное хранилище данных (КХД). КХД является основой для построения общей аналитической отчетности и, одновременно, служит базисом данных для Модуля НУ. Обычно, в соответствии с рекомендациями SAP, КХД строится на основе стандартного BW контента.
Здесь уместно сделать следующее замечание. Часто выделяются два основных подхода к ведению параллельного учета в SAP:
- Разделение видов учета при помощи выделения в общем плане счетов специальных «забалансовых» диапазонов.
- Разделение видов учета при помощи отдельных регистров в гибкой главной книге.
Поддерживаемая методология НУ
Конечным результатом решения является формирование отчетов, в соответствии с требованиями законодательства:
- Декларация по налогу на прибыль – имеет фиксированный формат, устанавливаемый законодательством. Отправляется в налоговые органы в виде XML файла, но должна иметь и обычное «бумажное» представление.
- Расчет налоговой базы ‑ сводный синтетический регистр расчета налога на прибыль, формируемый на основе аналитических регистров налогового учета, согласно статье 313 НК РФ.
- Аналитические регистры налогового учета ‑ обязательные отчетные формы, предусмотренные в статьях 313 и 314 НК РФ. Ниже, для краткости, они будут называться налоговыми регистрами. Их формат разрабатывается налогоплательщиком самостоятельно.
- Отчет о налоговых разницах – сводная отчетная форма. Показывает процесс начисления и списания постоянных и временных налоговых разниц в разрезе имеющихся в системе аналитических признаков. Одним из результатов отчета является определение базы для начислений и списаний отложенных налоговых активов и обязательств (ОНА/ОНО). Аналогично тому, как «Расчет налоговой базы» строится на данных налоговых регистров, «Отчет о налоговых разницах» строится на данных аналитических регистров разниц.
Как с методологической, так и с технической точек зрения, обязательным решением является введение промежуточного, между финальными отчетами и первичными документами, уровня хранения данных на котором происходит их налоговая классификация (присвоение номеров налоговых регистров и регистров разниц). Общая логическая структура потока данных проиллюстрирована на следующей схеме (Рис.1):
Рис.1. Логическая схема потока данных
Каждая строка Декларации формируется как простая сумма оборотов по одному или нескольким налоговым регистрам. Аналогично, «Отчет о налоговых разницах» строится на данных регистров разниц. Как Декларация, так и Отчет о разницах, являются виртуальными объектами. Уровень же регистров – это уровень хранения «вычищенных» и проклассифицированных данных, оптимизированный для решения конкретной задачи.
При переносе первичных документов из «Базиса Данных» в «Модуль НУ», происходит деривация номеров регистров. Правила деривации могут быть произвольного уровня сложности и использовать любую информацию, содержащуюся в первичных документах. Вместе с рассчитанным номером регистра сохраняются основные объекты контировок, например, номер счета, МВЗ, вид внутреннего заказа и т.п.
Согласно статье 313 НК РФ, подтверждением данных налогового учета являются первичные учетные документы (включая справку бухгалтера). В системе отдельные документы хранятся на уровне «Базиса данных» и в «Модуль НУ» не переносятся. Однако, всегда можно определить в какой регистр включен тот или иной первичный документ.
Согласно статье 313 НК РФ, подтверждением данных налогового учета являются первичные учетные документы (включая справку бухгалтера). В системе отдельные документы хранятся на уровне «Базиса данных» и в «Модуль НУ» не переносятся. Однако, всегда можно определить в какой регистр включен тот или иной первичный документ.
Технически, каждый регистр имеет уникальный номер и включен как объект самого нижнего уровня в следующую иерархию:
Рис.2. Иерархия налоговых регистров
Аналогично, для регистров разниц имеется следующая классификация:
Рис.3. Иерархия регистров разниц
Эта диаграмма показывает формат столбцов «Отчета о налоговых разницах». Его строки могут строиться как на иерархии налоговых регистров, так и на счетах РСБУ. Например, типичным требованием является «развертка» налоговых разниц по строкам Формы № 2. В целом, наличие полного набора требуемых аналитических признаков позволяет строить эффективные многомерные модели данных для OLAP отчетности.
Для целей налогового учета достаточно иметь единственный показатель – сумму оборотов в рублях. Временная гранулярность хранимых данных – финансовый период (месяц). При этом, следует иметь в виду, что год и период отнесения доходов и расходов в НУ и РСБУ могут не совпадать. Кроме того, особенности законодательства приводят к необходимости иметь в структуре данных дополнительную аналитику «Номер корректировки».
Деривация налоговых регистров и регистров разниц
Аналитические признаки налоговый регистр и негистр разниц, на которых строится вся налоговая отчетность, отсутствуют в первичных документах. При переносе информации из Базиса данных в Модуль НУ, происходит их деривация в два шага:
- номера регистров по умолчанию присваиваются бухгалтерским счетам и элементам затрат;
- окончательные номера регистров определяются при помощи настроенных в системе правил деривации.
Практика показывает, что реальные правила определения номеров регистров оказываются исключительно сложными. Во-первых, их много – каждая хозяйственная операция, для которой «не срабатывает» простой мэппинг на план счетов, порождает отдельное правило. Во-вторых, почти всегда в правилах присутствует ЕСЛИ-ТО логика, что делает процесс деривации ветвящимся. И, в третьих, в определении отдельных правил могут использоваться достаточно большие и меняющиеся со временем наборы объектов (например, номера счетов, ССП-элементов или внутренних заказов). Основная причина этих сложностей ‑ это, конечно, различие требований РСБУ и Налогового Кодекса. Но, часто, они бывают вызваны неисправимыми «огрехами» в настройках продуктивной системы, сделанными еще в процессе внедрения. Одним словом, это – тот самый случай, когда реальность оказывается сложнее «теории».
Деривация номеров регистров – ключевой узел всей системы. Если она не сможет заработать полностью автоматически, то претензия на формирование системой налоговой отчетности окажется несостоятельной, и бухгалтеру придется вернуться к привычной практике выгрузки промежуточных данных в Excel с их дальнейшей обработкой вручную.
Отчетность
Отчеты «Декларация по налогу на прибыль», «Расчет налоговой базы» и «Отчет о налоговых разницах» имеют фиксированный формат и служат, в числе прочего, «документарным» целям. Аналитические регистры налогового учета и регистры разниц являются реестрами первичных документов. Цифры в любом отчете должны быть проверяемыми. Поиск и исправление ошибок является едва ли не самой трудоемкой задачей, встающей перед бухгалтером в процессе повседневной работы. Для этой цели следует использовать такой мощный инструмент как OLAP отчетность в BW. Гибкие функции фильтрации данных и навигации позволяют решить задачи сверки и поиска ошибок оптимальным образом. Особенно полезна функция «проваливания» из отчета в отчет вплоть до первичного документа (drill-down).
Техническая реализация
Ниже описываются основные принципы технической реализации рассматриваемого решения. Следует сразу оговориться, что все её детали описать в одной статье невозможно. Поэтому целью автора является лишь дать читателю общее представление о том, как описанные выше (разделы?) требования могут быть адекватно реализованы при помощи инструментария SAP BW.
На следующей схеме (Рис. 4) изображены участвующие в процессе BW объекты и потоки данных между ними:
Рис. 4 Техническая схема потока данных.
Таблица 1. Объекты на схеме потока данных (Рис. 4).
При детальном описании потока данных, логично пойти снизу-вверх. Объекты, формирующие Базис данных, имеют прямые аналоги в стандартном SAP контенте (в простейшем случае, просто являются их копиями). Бухгалтерские документы из ERP реплицируются в DSO_04, результаты перераспределения косвенных расходов – в IC_03. Возможны ситуации, когда налоговые разницы возникают за счет проводок по разным счетам: начисления проводятся по одному счету, а списания – по другому счёту, отличному от первого. В DSO_01 подокументно сохраняется разность между такими начислениями и списаниями, то есть формируются сами разницы. DSO_05 хранит исходную информацию об амортизации ОС и НМА, а DSO_06 – о списании РБП. Для корректного расчета разниц необходимо анализировать данные из разных областей оценки. Это происходит в пользовательских программах трансформаций при переносе данных в DSO_02 и DSO_03. По сути, если бы задача была ограничена только расчетом базы налога на прибыль, то DSO_01, DSO_02 и DSO_03 были бы не нужны. Требование расчета налоговых разниц значительно усложняет всю техническую реализацию.
Инфо-источник IS_01 создает универсальный интерфейс для входящего потока данных для алгоритма деривации номеров регистров. Деривация происходит в программе запуска в трансформации из IS_01 в IC_01. Сам алгоритм требует гибкого инструмента настроек. Для реализации используется технология BRF+ (Business Rules Framework Plus), позволяющая задавать правила произвольного уровня сложности при помощи универсального графического интерфейса. Поскольку созданные правила автоматически компилируются в АВАР код, данный подход является оптимальным для использования внутри пользовательских программ в трансформациях. Инфо-куб IC_01 содержит все данные, необходимые для формирования отчетности по налогу на прибыль и налоговым разницам. Для расчетов при помощи функций планирования служит инфо-куб реального времени IC_02. В частности, в нем решается задача расчета налога на прибыль по обособленным подразделениям. На мульти-провайдерах MP_01 и MP_02 строится отчетность. Кроме того, MP_02 служит в качестве базового провайдера для уровней агрегации, реализующих BI-IP функции, такие как копирование налоговой базы и расчеты при помощи функций планирования.
Репорт-репорт интерфейсы создают потоки данных в обратном направлении, вплоть до первичных документов в ERP. При этом отчеты, участвующие в интерфейсах строятся на виртуальных инфо-провайдерах, являющихся своего рода оболочками над реальными DSO.
Что дальше?
Отчетности по налогу на прибыль, НДС и имущественным налогам тесно связаны. Например, корректировка декларации для одного из этих налогов автоматически требует корректировки и для другого налога. Формирование Декларации по НДС в BW является вполне естественным решением. А учитывая возможности, предоставляемые OLAP отчетностью для сверок и поиска ошибок, такое решение даст бухгалтеру мощные инструменты, которых он, по определению, лишен в ERP. Поскольку база данных об основных средствах уже создана в рамках автоматизации налога на прибыль, естественным решением является построение на ее основе отчетности по имущественным налогам.
Автор: Дмитрий Булатов
Кандидат физико-математических наук. Более 25 лет опыта внедрения информационных систем в различных отраслях экономики. Экспертные знания архитектуры платформ SAP ERP и SAP BI. Глубокое понимание предметных областей финансового и управленческого учета, бюджетирования и консолидации. Успешный опыт построения комплексных архитектур SAP BI и SAP ERP на российских и международных проектах. Эксперт в функциональностях SAP BW, FI, CO, FI-FM.