Налоговый учет в sap

Опубликовано: 03.05.2024

Упростите ведение национального и налогового учета с модулем SAP FI

Сократите время на создание финансовой отчетности с SAP FI

Модуль SAP “Финансы” (FI) — решение, которое позволяет отражать необходимые хозяйственные операции, вести учет активов и пассивов компании и формировать финансовую отчетность.

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

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

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

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

Вести финансовый учет с SAP FI — значит обеспечить максимальную прозрачность и скорость операций

В числе преимуществ ведения финансовой отчетности в SAP FI:

Полная прозрачность всех действий в системе

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

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

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

Оценка основных средств, нематериальных активов, капитальных вложений и запасов компании

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

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

SAP FI позволяет вести учет в нескольких валютах и по нескольким стандартам (национальному, международному, управленческому).

Финансовый и календарный год

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

Однократный ввод данных в систему

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

Опыт экспертов LeverX поможет вашему бизнесу воспользоваться всеми преимуществами SAP FI для ведения национального и налогового учета

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

Налог на добавленную стоимость (НДС);
Налог на прибыль;
Налог на имущество;
Земельный налог;
Транспортный налог;
Налог по водным ресурсам и др.

География наших проектов по национальному и налоговому учету охватывает Беларусь, Россию, Украину, Узбекистан, Литву, Латвию, Швейцарию, Германию, Азербайджан, Грузию, Казахстан, Румынию.

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

Мы рады ответить на все вопросы по модулю SAP “Финансы” и его преимуществах для вашего бизнеса!

Считаете ли вы, что корректно настроенная ERP-система способна серьезно упростить ведение налогового учета?

четверг, 26 августа 2010 г.

Программные продукты SAP для автоматизации налогового учета

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

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

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

Что касается первой и главной особенности, то возможность вести параллельный налоговый учет на текущий момент реализована в большинстве ERP-систем. Однако необходимо отметить, что в некоторых системах по-прежнему используется подход на основании трансформации бухгалтерских данных. Компания SAP разработала решение по налоговому учету, основанное на ведении параллельного учета, в 2002 г., т.е. практически сразу после выхода в свет главы 25 НК РФ. Данное решение предполагает однократный ввод первичного документа в систему. При этом на основании документа формируются как бухгалтерские, так и налоговые показатели, что и лежит в основе принципа параллельного налогового учета. Этот подход, во-первых, избавляет бухгалтера от двойной работы по вводу одного и того же документа для целей бухгалтерского и налогового учета, а во-вторых, связывает информацию по налоговому учету с первичными бухгалтерскими документами, что позволяет оперативно формировать пакет документов для подтверждения налоговых доходов и расходов.

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

Учет расходов на страхование

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

Бухгалтерский и налоговый учет расходов на страхование имеет существенные отличия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ф. ЛЕБЕДЕВ,
старший консультант отдела консалтинга в области финансов, SAP СНГ

К. НИКИТИН,
партнер отдела налогообложения PricewaterhouseCoopers

Д. СУРЧЕНКО,
консультант проектов группы методологической поддержки налогового учета в ERP-системах PricewaterhouseCoopers

С. САРАЕВ,
менеджер проектов группы методологической поддержки налогового учета в ERP-системах PricewaterhouseCoopers

Ануфриева Татьяна Юрьевна – студент магистратуры Волгоградского государственного университета.

Аннотация: Рассматривается типовой бизнес-процесс формирования налоговой отчетности на примере системы SAP HR. Предлагается алгоритм сбора данных для автоматизации формирования отчетных форм по налогу на доходы физических лиц с детализированной информацией по типам дохода в разрезе каждого работника для осуществления функции налогового мониторинга.

Ключевые слова: Корпоративные информационные системы, программное обеспечение, sap, налоговая отчетность, налоговый мониторинг.

Введение

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

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

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

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

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

Однако стандартный функционал системы SAP ERP не позволяет формировать детализированные отчетные формы по НФДЛ [3]. Для примера рассмотрим форму 6-НДФЛ. Согласно требованиям налогового мониторинга, необходима возможность расшифровки дохода из 1 раздела этой формы в разрезе ИНН работника и каждого типа начисления и вычета. Но реализованный алгоритм сбора данных для такой отчетности отсутствует.

Описание бизнес-процесса формирования налоговой отчетности

В SAP ERP существует решение по базовым процессам по управлению персоналом – SAP HR. В данном функционале происходит расчет заработной платы, на основании данных которого формируются такие налоговые отчетные формы, как справка 2-НДФЛ, форма 6-НДФЛ.

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

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

На следующем этапе сотрудник расчетной группы производит расчет заработной платы, осуществляет выплату средств, перечисление страховых взносов во внебюджетные фонды, удержаний НДФЛ, иных платежей. Результатом являются рассчитанные, проанализированные и отраженные в финансовой информационной системе в виде бухгалтерских проводок данные по расчету заработной платы. Произведенные расчеты служат основой для формирования отчетности [5].

Далее происходит формирование отчетности для организации и контроль ее корректности на основании расчетных данных по заработной плате экспертом в налоговой отчетности. Для формирования отчетов в продуктивной системе SAP HR должна быть рассчитана заработная плата за соответствующие месяцы налогового периода. Результатом является сформированные в системе формы налоговой отчетности по НДФЛ: «Налоговый регистр», справка 2-НДФЛ (формируется отдельно по каждому физическому лицу), форма 6-НДФЛ (формируется в целом по организации).

Алгоритм сбора данных

В стандартном функционале системы SAP HR в выходных налоговых отчетных формах нет детальной информации в разрезе каждого типа начисления. Поэтому стоит задача на основании принципа формирования справки 2-НДФЛ реализовать сбор данных для полного раскрытия сведения о доходах. Предлагается формат, описанный в таблице 1.

Булатов Дмитрий

26 февраля 2016, 15:26

В статье описывается методология и техническая реализация требований 25-ой главы НК и ПБУ 18/02 с помощью инструментов, предоставляемых SAP BW.

С момента принятия в 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, как правило, приводит к изменению их классификации, с точки зрения НУ. Кроме того, часто непростой задачей является явное выделение капитализируемых расходов и НЗП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

Практика использования программ учета - SAP и 1 С

Вот возникло желание поделиться своими впечатлениями, с точки зрения бухгалтера и аудитора, от использования таких программ учета как SAP и 1 С.

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

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

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

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

Сразу отмечу, что 1С по сравнению с программой SAP, мое мнение, намного проще и понятнее в использовании, особенно для новичка.

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

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

Но в 1С полномочия разных\других специалистов разграничивается правом на использование того или иного интерфейса.

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

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

Изучить же самостоятельно учет в программе SAP, как по мне, намного сложнее. А что-то самостоятельно добавить (отчет, счет, статью затрат (МВЗ)) – в принципе невозможно, это делается только «поддержкой» - консультантами.

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

регистрация входящего налогового документа и т.д. ).

В SAP же существует два метода введения данных: или выбор операции с общего меню, (в принципе сопоставимо с 1С), или введение транзакции в определенную ячейку. И каждому пользователю устанавливаются полномочия на использование той или иной транзакции. Название этих транзакций - это набор цифр и букв, который не имеет ничего общего с названием операции, что, на мой взгляд, является очень неудобным способом ввода операций (на пример - FB65,KO88 и т.д.).

Счета учета: В 1 С длина счета составляет четыре знака, в SAP – восемь знаков, что позволяет получить, при необходимости, более детальную аналитику.

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

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

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

Что-то похожее есть и в 1С при внесении начальных остатков, когда задействован нулевой счет. Но это разовая операция, в программе SAP же – использование транзитных счетов обычная практика.

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

Справочники и возможность унифицировать учет: Как в SAP, так и в 1 С можно настроить единые справочники (материалы, контрагенты, статьи доходов и затрат и т.д.) и установить их централизованное ведение.

Но в 1С присутствует более обобщенная классификация справочников, что позволяет пользователю принимать самостоятельно решение при выборе счета учета.

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

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

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

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

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

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

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

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

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

Из воспоминаний своей практики – сначала пользователи возмущались, а потом как оказалось, это очень даже дисциплинирует.

Операции выравнивания данных в учете: Периодически, в SAP необходимо проводить операции выравнивания по счетам, при этом формируется отдельный документ. Эта операция позволяет свернуть данные учета по отдельным счетам, в частности по счетам учета аванса и счетам поступления/продажи товаров и услуг (371* и 631*, 361* и 681*, и т.д.).

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

Контролинг: Самым большим преимуществом ведения учета в программе SAP над 1С, является, мой взгляд – контролинг. В 1 С учет доходов и затрат возможно построить используя статьи затрат и подразделения.

В SAP же, учет затрат построен по местах их возникновения (МВЗ), за видами затрат, распределение и раскладка за план-фактом. Это позволяет организовать очень детальную аналитику, отследить перерасчет затрат между подразделениями, построить оперативный расширенный управленческий учет.

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

Читайте также: