Ремонты, модернизация, улучшения основных средств в налоговом учете

[Таня]

Впервые столкнувшись с «решением» SAP для Украины, испытала противоречивые чувства. Одним из них было стойкое желание описать особенности решения и как с ними бороться и жить дальше. Информация, которую я смогла найти, меня совершенно не удовлетворила (ноты sapnote_0000783199, sapnote_0001464301, sapnote_0001695110, sapnote_0001704927). Делаю скидку, конечно, на то, что я новичок в этом деле, но ведь не я одна. Думаю, описание будет полезным.
Итак, налоговый учет и ремонты (читай – ремонты, модернизация, реконструкция, улучшения и пр. подобные операции с основными средствами).
В налоговом учете Украины есть возможность отнести на валовые расходы стоимость ремонтов основных средств, которая не превышает 10% от балансовой стоимости всех основных средств на начало отчетного года .
Т.е. нам нужно все ремонты, которые мы выполняем, за месяц, проанализировать на предмет превышения/достижения 10% балансовой стоимости производственных необоротных активов на начало текущего года, и в случае не достижения 10% - отнести на валовые расходы, в случае же превышения – увеличить стоимость основного средства в налоговой области оценки. В этом процессе два учета – бухгалтерский и налоговый – расходятся и должны быть параллельно отражены. В бухгалтерском учете – текущие ремонты всегда относятся на затраты, все что приводит к увеличению будущих выгод от использования улучшенных основных средств – должно капитализироваться, увеличивая при этом стоимость улучшенного основного средства.
Итак, нам предлагается воспользоваться программой J_1UF_MAJOR_REPAIR. Транзакция - J1UFFAR - Ремонти основних засобів.
Тут есть немного информации, правда даже в этой капле допущены некоторые неточности.
Программа создавалась еще для старого налогового учета, в котором использовались различные методы амортизации для разных групп и начисление амортизации, а соответственно периодичность анализа для учета ремонтов, выполнялось поквартально. Изменения налогового учета привели лишь к небольшим изменениям в программе.

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

146.12. Сума витрат, що пов'язана з ремонтом та поліпшенням об'єктів основних засобів, у тому числі орендованих, у розмірі, що не перевищує 10 відсотків сукупної балансової вартості всіх груп основних засобів на початок звітного року, відноситься до витрат того звітного податкового періоду, в якому такі ремонт та поліпшення були здійснені.

• 
  Для того, чтобы иметь возможность анализа ежемесячно необходимо установить ноту Note 1643903 - Major Repair Ukraine: Monthly calculation. Этот нюанс в справке не отражен. Да и справка по транзакции осталась старая.
  
• 
  В справке указано: «Программа обрабатывает записи таблицы ремонтов основных средств J_3RFCAPREP. Ведение таблицы может осуществляться вручную через ракурс ведения J_3RFCAPREP с помощью транзакции SM30 или автоматически при расчете заказа ТОРО посредством выполнения пользовательского функционального модуля», что тоже оказалось лукавством – функционального модуля, который позволит заполнять данную таблицу автоматически из ТОРО не оказалось...(по словам коллег из ТОРО).
  
• 
  Важный момент - программа работает только, если существует балансовая стоимость на начало года. Где-то это даже логично, какие могут быть ремонты, если у компании все новенькое. Но вот такую информацию дать не мешало бы. Поскольку при настройке системы, как правило, остатки еще не перенесены, а процесс отражения ремонтов как то тестировать и настраивать нужно.
  
• 
  Как атавизм осталась необходимость ведения таблицы J_1UFTASSGROUP (через SM30). При ведении ракурса код группы (при том, что это «условное» поле, ничему не соответствующее) должен быть не 0. Наследие прошлого, когда каждая группа имела собственный код амортизации, и на сумму ремонтов увеличивалось не отдельное ОС, а выбранное и указанное в таблице, т.е. повышалась стоимость группы.
  И это надо будет вводить на каждый год...на каждый квартал...
  

И тут самое интересное. Никак не могла понять – почему при тестировании отнесения сумм ремонтов на затраты (при не достижении 10% рубежа) затраты повторно дебетуются? Т.е. нужно потом руками сторнировать проводки? Спасибо, хоть поступление на карточки ОС (при превышении 10% рубежа) не задваивалось.... Почему в расчет включаются позиции предыдущих периодов? Получается, что затраты на ремонт, отнесенные на затраты в налоговом учете, каждый прогон программы пересчитываются, несмотря на отраженные уже затраты в предыдущих периодах. Можно ли записать в таблицу номер финансового документа – по отраженным затратам?
В ходе расследования обнаружилась следующая программная проблема:
в программе J_1UF_MAJOR_REPAIR, строка 134, система определяет текущий период работы следующим образом

Код Виділити Розширити

CONCATENATE  zgjahr '0101' INTO date_ybeg.
CONCATENATE  zgjahr '1231' INTO date_yend.
date_yend = date_ybeg - 1.                                "n.834541(b)

zgjahr – вводится с экрана, 2012 год
date_ybeg – формируется как дата начала года, 20120101
date_yend – дата конца года, 20121231,
далее в третьей строке эта дата = дата начала года – 1, в итоге в поле date_yend записывается дата 20111231, т.е. дата конца периода оказывается меньше даты начала.
Далее, в программе J_1UF_MJR_FORMS, со строки 514 имеем следующий код:

Код Виділити Розширити

SELECT  BELNR GJAHR BKTXT BUDAT
*SELECT  BELNR GJAHR BUDAT INTO  (V_BELNR, V_GJAHR,          "n.846437
FROM BKPF
INTO  (V_BELNR, V_GJAHR, P_BKTXT, POST_DATE)
WHERE BUKRS = P_BUKRS AND
      BSTAT = ' ' AND
      XBLNR = P_XBLNR AND
      STBLG = ' '  AND
*      BKTXT = P_BKTXT AND                                  "n.846437
      BUDAT BETWEEN DATE_YBEG AND DATE_YEND.

Который, судя по всему, пытается найти уже проведенные документы по отраженным затратам на ремонт, но так как период поиска с 01.01.2012 по 31.12.2011, то данный select ничего не находит. Система не видит проведенных финансовых документов, не записывает их номера в отчет, не контролирует суммы. Изменив в отладке дату с 20111231 на 20121231 год, получила корректный результат.

Даты нот n.834541(b) – 15/04/2005;    n.846437 – 29/07/2005.

На обращение к «владельцу» данной красоты, был получен ответ, что, дескать, этой программой пользуются многие клиенты и их все устраивает.
Разрешилась ситуация установкой ноты Note 1689857 - J_1UF_MAJOR_REPAIR: Cost-center in FI-document is empty (дата выпуска ноты 05/04/2012).

• 
  Резюме. Логика такая – проводятся затраты до исчерпания 10% лимита, остальное пропорционально позициям в указанном квартале (работает галка Корректировка квартала) начинает поступать на карточки (если на квартал осталась сумма частично на повышение стоимости, частично в затраты). То, что уже проведено по затратам записывается номером документа в отчет и светофор становится зеленым (рисунок Rep_1.png).
  Если в пределах квартала возникает необходимость пересчета – сумма затрат сторнируется автоматически. Поступление на карточки и сторно поступлений также выполняется автоматически.