С момента принятия в 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. Перечислим их:

• Разделение прикладной функциональности и "Базиса данных" с целью добиться максимальной независимости от деталей реализации хранилища исходных данных.
• Четкая формулировка поддерживаемой методологии учета, с заранее предусмотренными возможностями настройки и расширения. Исходя из этого, фиксируется набор аналитических признаков и показателей, составляющих модель данных НУ.
• Алгоритмы трансформации при переносе из Базиса данных в модель данных НУ должны быть максимально гибкими и, одновременно строго "заточенными" под решаемую задачу.
• Система отчетности должна быть встроена в прикладную функциональность.

Для краткости будем называть описываемое в статье решение по реализации требований 25 главы НК и ПБУ 18/02 "Модуль НУ". Изложение структурировано по разделам.

Базис данных.

Все исходные данные первоначально сохраняются в таблицах ERP системы. Для налогового учета представляют интерес следующие SAP модули:

• FI-GL – Главная книга. На практике, чаще всего встречается Гибкая главная книга с выделенным "налоговым" регистром. Однако это не является обязательным требованием.
• FI-AA – Учет ОС и НМА. Предполагается, что имеются следующие области оценки:
  • оценка в соответствии с РСБУ;
  • оценка в соответствии с требованиями 25 главы НК;
  • постоянные налоговые разницы;
  • налоговые разницы без постоянных разниц.
• FI-GL-ACE – Расходы и доходы будущих периодов (Accrual Engine). Использование данного модуля является опциональным. Иногда списание расходов будущих периодов настраивается в модуле учета ОС FI-AA.
• CO-OM – Контроллинг косвенных затрат. Перераспределение расходов внутри модуля СО-OM, как правило, приводит к изменению их классификации, с точки зрения НУ. Кроме того, часто непростой задачей является явное выделение капитализируемых расходов и НЗП.

Все необходимые данные импортируются из ERP в систему BW, где формируется корпоративное хранилище данных (КХД). КХД является основой для построения общей аналитической отчетности и одновременно служит базисом данных для Модуля НУ. Обычно, в соответствии с рекомендациями SAP, КХД строится на основе стандартного BW контента.

Здесь уместно сделать следующее замечание. Часто выделяются два основных подхода к ведению параллельного учета в SAP:

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

На практике, ни один из этих подходов не встречается в чистом виде. Всегда приходится иметь дело с некоторой их смесью, когда "мирно сосуществуют" как выделенный регистр ГК для НУ, так и специальные "налоговые счета". При этом основной массив информации естественным образом дублируется. Это требует определенного внимания, чтобы одна и та же хозяйственная операция не попала в отчеты больше одного раза. В частности, строить налоговую отчетность следует непосредственно на данных модуля FI-AA, "отфильтровывая" соответствующие проводки по ГК. Это же замечание относится и к расходам/доходам будущих периодов, списываемым при помощи Accrual Engine (Разграничения вручную). Что касается Контроллинга, то представляется целесообразным брать проводки по первичным элементам затрат из бухгалтерских документов, анализируя для целей НУ только внутриконтроллинговые перераспределения.

Поддерживаемая методология НУ.

Конечным результатом решения является формирование отчетов, в соответствии с требованиями законодательства:

• Декларация по налогу на прибыль – имеет фиксированный формат, устанавливаемый законодательством. Отправляется в налоговые органы в виде XML файла, но должна иметь и обычное "бумажное" представление.
• Расчет налоговой базы ‑ сводный синтетический регистр расчета налога на прибыль, формируемый на основе аналитических регистров налогового учета, согласно статье 313 НК РФ.
• Аналитические регистры налогового учета ‑ обязательные отчетные формы, предусмотренные в статьях 313 и 314 НК РФ. Ниже, для краткости, они будут называться налоговыми регистрами. Их формат разрабатывается налогоплательщиком самостоятельно.
• Отчет о налоговых разницах – сводная отчетная форма. Показывает процесс начисления и списания постоянных и временных налоговых разниц, в разрезе имеющихся в системе аналитических признаков. Одним из результатов отчета является определение базы для начислений и списаний отложенных налоговых активов и обязательств (ОНА/ОНО). Аналогично тому, как "Расчет налоговой базы" строится на данных налоговых регистров, "Отчет о налоговых разницах" строится на данных аналитических регистров разниц.

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

Рис.1. Логическая схема потока данных

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

При переносе первичных документов из "Базиса Данных" в "Модуль НУ", происходит деривация номеров регистров. Правила деривации могут быть произвольного уровня сложности и могут использовать любую информацию, содержащуюся в первичных документах. Вместе с рассчитанным номером регистра сохраняются основные объекты контировок, например, номер счета, МВЗ, вид внутреннего заказа и т.п.

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

Технически каждый регистр имеет уникальный номер и включен как объект самого нижнего уровня в следующую иерархию (Рис.2):

Рис.2. Иерархия налоговых регистров

Аналогично, для регистров разниц имеется следующая классификация (Рис.3):

Рис.3. Иерархия регистров разниц.

Диаграмма (Рис.3) показывает формат столбцов "Отчета о налоговых разницах". Его строки могут строиться как на иерархии налоговых регистров, так и на счетах РСБУ. Например, типичным требованием является "развертка" налоговых разниц по строкам Формы № 2. В целом, наличие полного набора требуемых аналитических признаков позволяет строить эффективные многомерные модели данных для OLAP отчетности.

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

Деривация налоговых регистров и регистров разниц

Аналитические признаки налоговый регистр и регистр разниц, на которых строится вся налоговая отчетность, отсутствуют в первичных документах. При переносе информации из Базиса данных в Модуль НУ, происходит их деривация в два шага:

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