Добрый день коллеги. Кто-нибудь пользуется таким методом расчета амортизации? Если да, то подскажите пожалуйста, каким образом.

Мы такой метод расчета амортизации не используем, но попробуйте настроить методы по этапам таким образом:
9999 999 12 27 0,0000% V(остат. срок)
И еще проверьте видит ли такой код амортизации оставшийся срок службы после перемещения на новую карточку.

Настроил код амортизации как смог, дальше не получается. Считает от оставшегося срока службы, но типовая амортизация поступления почему то считается от первоначального срока эксплуатацию. Где же это настраивается?

К примеру, такие настройки кода амортизации:
базовый метод Типов.: %% по сроку эксплуатации
метод/период: 11/11/11/11
метод по этапам: 9999 999 12 27 0,0000% V(ост срок)
класс: без присвоения
Все работает.
В любом случае получается месячная амортизация= ост.ст-ть/ост.срок это есть линейная амортизация.

Все-равно при этих настройках типовая амортизация дополнительного поступления считается от первоначального срока эксплуатации, а должна от остаточного.
Допустим, поступило ОС в январе на сумму 120 тыс. - срок эксплуатации ровно 10 лет (120 мес.). Месячная амортизация будет равна:
1 тыс. = 120 тыс / 120 месяцев.
В ноябре провели модернизацию этого ОС на сумму 110 тыс. Соответственно, в декабре месячная амортизация должна быть равна:
2.000 = ( ( 120.000 - ( 1.000 * 10 мес) + 110.000 ) / 110,
но месячная амортизация в декабре равна 1.916,67.
Потому что, в SAPе считается амортизация поступления от первоначального срока эксплуатации:
110.000 / 120 мес = 916,67.

Вопрос: как можно сделать правильный расчет месячной амортизации от остаточной стоимости?

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

Без новой карточки мне кажется не обойтись, т.к. во многих случаях модернизация подразумевает пересмотр срока службы, а изменение срока в текущей карточке приводит к каким-то не очень понятным пересчетам в след месяце.
У меня другой вопрос Сделали как предлагается код амортизации с этапом с ссылкой 27. В текущем году все нормально, а в след. уже другая амортизация, т.е. он берет остаточное значение каждый год на начало. как быть?

А галочку остаточный срок ставили?

Manicomio прав, в данном случае не обойтись без нового ОС или субномера.


Должен обязательно стоять в методе по этапам крыжик оставшегося срока службы.

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

Спасибо за галку, действительно забыл.

А что за пользовательская амортизация, где живет, чего делает?

Система позволяет осуществлять изменения отдельных стандартных функций с помощью собственных функциональных модулей (через SAP-расширения).
Примеры SAP-расширений:
AFAR0001 - Определение ссылочного значения для расчета амортизации;
AFAR0002 - Метод расчета амортизации и т.д.
Подробнее посмотрите в SAP Library.

Мы используем в таком случае ссылочное значение 24, а не 27 . Чем они отличаются, вернее на что это может повлиять, кто знает?
При модернизации чуть ли с каждым объектом приходится индивидуально работать.

Ссылочное значение 27 учитывает поправку стоимости, например, при перемещении на новую карточку ОС остаточная стоимость рассчитывается, учитывая поправку стоимости.

Странно, что в SAP нет стандартного решения этой проблемы.

Dumer, для вы писали расширение AFAR0001 - Определение ссылочного значения для расчета амортизации? Если уже созданы ОС с неправильным расчетом амортизации, повлияет ли внедрение данного расширения, осуществится ли перерасчет старых ОС?