Амортизация после кап.ремонта по НУ

[sns]

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

Первоначальная стоимость ОС = 60 000р
Срок службы = 60 мес.
Начисляли амортизацию 8 мес = 8 000р
Потом провели кап.ремонт = 18 000р
После этого амортизация должна начисляться по 1300р каждый месяц еще ! 54мес! .

Можно ли добиться такого эффекта с помощью стандартного функционала?
Вариант начисления способом "вручную" нежелателен.

[ppson]

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

[sns]

Именно таким способом мы пользуемся, что бы удовлетворить требования РФ к бух.учету модернизированных ОС :-)
Но сумму в 1300руб применяя такой способ мне получить не удалось :-(

[sns]

Что бы понять все тонкости вопроса см. Письмо ФНС от 14.03.05 N 02-1-07/23.
Рассчитывая сумму амортизации от остаточной стоимости мы не получим нужную сумму ежемесячно. Рассчитывая сумму от балансовой величины мы списываем завышенную величину в последний месяц срока службы оборудования.

[ppson]

Цитата:

Сообщение от sns

к бух.учету модернизированных ОС :-)

Бухгалтерскому или налоговому?

[sns]

Дополняю:

По бух. учету в моем примере положено считать:

(60000+18000-8000)/(60-8)=1346,15руб каждый месяц всего 52 месяца

По НУ положено считать:

78000/60=1300 в течении 52 месяцев,
1300руб - в 53 месяце
1100руб - в 54 месяце (см. вышеназванное письмо ФНС,
а также письмо УФНС по г.Москва от 16.06.06 N 20-12/53521@ и проч.)

[TasmanianDevil]

Цитата:

Сообщение от ppson

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

Это, простите, где там обитает такое поле ?
В форме методов амортизации нет поля с названием "расчет амортизации" ни в 3-ке, ни в 4-ке в стандартном функционале (морды лица формы - в присобаченном. Скрытых полей нет. Форма живет на DIS и не модифицировалась)

Может это модификация какая-то у Вас ?

[Кирилл Егоров]

А откуда берутся 54 месяца?

[TasmanianDevil]

sns, как это

Цитата:

Сообщение от sns

По НУ положено считать:
78000/60=1300 в течении 52 месяцев,
1300руб - в 53 месяце
1100руб - в 54 месяце (см. вышеназванное письмо ФНС,
а также письмо УФНС по г.Москва от 16.06.06 N 20-12/53521@ и проч.)

сочетается с этим

Цитата:

Сообщение от sns

В налоговом учете РФ есть требование:
если в результате кап. ремонта срок службы не изменился, то ...

В связи с этим вопросы :
1) Таки все же , почему 54 вместо 52 ?
2) Деление 78000/60 - это формула для каждого месяца ? Остаточная стоимость на дату начисления поделить на полный срок даст бесконечный цикл амортизации, последний кусок, меньший настройки округления суммы амортизации, будет списываться целую вечность. Что значит сия формула в Вашем примере ?

Мы дописывали свой метод для ежемесячного начисления амортизации, для каждого периода начисления сумма амортизации = остаточная стоимость / оставшийся срок.

При тком способе в строго положенный срок ОС самортизируется наиболее близко к БУ(а в идеале идентично), дабы не порождать всякого рода разницы амортизаций по ПБУ 18/02.

[Михаил Андреев]

Поле "Расчет амортизации" штатное. И для версии 3.0, и для версии 4.0.

[TasmanianDevil]

Цитата:

Сообщение от Михаил Андреев

Поле "Расчет амортизации" штатное. И для версии 3.0, и для версии 4.0.

Михаил, давайте все-таки разберемся по порядку.

3-ка SP3
Поля таблицы RAssetDeprProfile :
1) DeprProfile - собственной метки не имеет, наследует метку от EDT RAssetDeprProfileId "Метод амортизации", идентификатор записи в каталоге методов.
2) DeprMethod - аналогично п.1, наследует метку от Enum RAssetDeprMethod "Метод". Фактически определяет алгоритм расчета (является аргументом в конструкторе RAssetTableMethod для наследников). В своем составе у элементов enum не имеется метки, содержащей "по восстановительной стоимости".
3) DeprInterval - аналогично п.1, наследует метку от enum DeprInterval "Интервал". В своем составе у элементов enum не имеется метки, содержащей "по восстановительной стоимости".
4) DeprPercentage - аналогично п.1, наследует метку от EDT RAssetDeprPercentage "Коэффициент"
5) Name - без вопросов и пояснений
6) CostLimit - аналогично п.1, наследует метку EDT RAssetCostLimit "Граница стоимости"
7) Monthly - банальный NoYes с меткой "Ежемесячно"
Форма и Enum - не модифицировались.
Нет поля с такой меткой и содержанием.

4-ки под рукой сейчас нет , потому беру User manual от В.Корепина (том 2, ISBN 978-5-9790-0045-9), смотрим страницы 652 - 654(особенно 653, где регламентируется видимость полей на "Разном" в зависимости от выбора метода). Нет поля с таким нименованием, не упоминается вообще.Стр. 666-670, на которых вкратце даются описания методов и скриншоты, тоже не содержат упоминания поля с таким именем и содержанием.

Может быть все-таки у Вас модификация какая-то ?
Меточный файл измененный ?
Как по репозитарию обзывается поле в RAssetDeprProfile, которое по Вашим словам имеет метку "Расчет амортизации" ?

P.S. Стою на асфальте, в лыжи обутый

[Raven Melancholic]

Цитата:

Сообщение от TasmanianDevil

3-ка SP3
Поля таблицы RAssetDeprProfile :
...

Ключевое слово SP3. В SP5 появилось поле DeprSumBase, Base enum которого RAssetDeprSumBase. Именно там и "спрятано" значение, которое вызвало вопрос. Насчет книги не знаю (у меня не 2-х, а 3-х томник, там скриншота с настройкой методов амортизации вообще нет, но только что посмотрел в четверке это поле есть при выборе линейного метода)

[TasmanianDevil]

Raven Melancholic, насчет 3-ки понято и принято ...
Странно, что в упомянутом мануале по 4-ке оно не упоминается.

[sns]

Отвечаю на вопросы:
В связи с этим вопросы :
1) Таки все же , почему 54 вместо 52 ?

Потому что Советский (тьфу, Российский) учет самый правильный учет в мире.

2) Деление 78000/60 - это формула для каждого месяца ? Остаточная стоимость на дату начисления поделить на полный срок даст бесконечный цикл амортизации, последний кусок, меньший настройки округления суммы амортизации, будет списываться целую вечность. Что значит сия формула в Вашем примере ?

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

[gaenar]

Допустим, если ОС уже отжил свои 60 месяцев, а на 61 месяце его отмодернизировали на 10 000 руб. без увеличения срока полезного использования.

Как в этом случае считается БУ? В знаменателе ноль.
А по НУ вроде всё красиво, (60 + 10) / 60 будут списываться по 1366, пока не спишутся, ещё год.

[Nuta]

Цитата:

Сообщение от sns

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

Первоначальная стоимость ОС = 60 000р
Срок службы = 60 мес.
Начисляли амортизацию 8 мес = 8 000р
Потом провели кап.ремонт = 18 000р
После этого амортизация должна начисляться по 1300р каждый месяц еще ! 54мес! .

Можно ли добиться такого эффекта с помощью стандартного функционала?
Вариант начисления способом "вручную" нежелателен.

Подскажите, пожалуйста, удалось ли Вам решить вопрос со сроком списания?
У меня такая же проблема в Налоговом учете. Сумму удалось получить правильную (путем выбором способа расчета амортизации По восстановительной стоимости). Но в последний месяц срока окончания списывается вся оставшаяся сумма, а не продлевается амортизация дальше.
у нас Аксапта 4.0 Sp1.