Коллеги, всем добрый день!
Разбираюсь в новой для меня теме – основных средствах)
Бьюсь с расчетом типовой амортизации после модернизации в версии системы 6.0 с новой амортизацией по периодам.
EA-FIN активирован, все доп.поля в карточке ОС активированы.
Заказчик хочет работать без субномеров – в той же карточке ОС.

Пример:
ПСт ОС = 70 000, срок эксплуатации = 7 месяцев.
Первые 4 месяца амортизация начисляется линейно по 10 000р.

В середине года происходит модернизация (еще +30 000) и после нее расчет идет от остаточной стоимости(ссылочное значение23) по оставшемуся сроку (галка «ост.срок» установлена).

Вопрос 1.
Неправильно отрабатывает код амортизации по Ост стоимости - после модернизации система берет полную стоимость всех поступлений (100 000) и умножает на норму амортизации за 3 месяца (3/7), а не берет остаточную стоимость(60 000) и не делит на остаточный срок(3 мес), как должно быть.

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

Вопрос 2.
Если после модерн-ции меняю срок эксплуатации и дату начала начисления аморт-ции, то система рассчитывает ВСЮ амортизацию с начала года только по новому измененному сроку и дате.

Как сделать так, чтобы при изменении срока использования и даты начала расчета, система не пересчитывала всю амортизацию с начала года?

Как сделать так, чтобы при изменении срока использования и даты начала расчета, система не пересчитывала всю амортизацию с начала года?

Добавить новый интервал.

Использовать пользовательский метод расчета амортизации.
Для версий до 6.0 - см. расширение AFAR0002 (поищите по форуму).
Для 6.0 - см. BADI FAA_EE_CUSTOMER
http://sapboard.ru/forum/viewtopic.php ... t=afar0002

Спасибо, только вот задание нового интервала не помогает. Конечно же я задавала новый интервал, потому что у меня после модернизации код амортизации меняется - сначала линейный от первоначальной стоимости, а потом от остаточной стоимости. Вот только при задании нового интервала можно проставить дату начала интервала, а дата начала расчета типовой амортизации от интервалов не зависит. Она одна. И если ее менять, то пересчитывается вся амортизация с начала года. У меня система так работает по крайней мере)

Очень хочется сделать все стандартом, и не дописывать свой пользовательский метод...
Deinis, а Вы писали новый метод? Вам стандартные не подошли?

Мы пока ничего не писали. Тестируем, насколько это дело нам подойдет. В SAP-ноте 963414 уже содержится вроде подоходящий пользовательский метод. Можно создавать и свои методы. Потестировали - имеющийся вроде даже и работает. И, насколько видим, правильно. Рассказали пользователям. Теперь ждем ответа от них.

а переместить на новую карточку после реконструкции не пробовали? там же и код меняется, на "от остаточной стоимости и остаточного срока"

насколько помню, на всех моих проектах мы делали это правило обязательным

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

нюню )

интервалы работают адекватно

вам сапу придется предъявлять требование перейти от понятия "остаточный срок на начало года" к "остаточный срок на текущий момент"

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

Нашим тоже не нравится перемещение, но даже они под это прогнулись. Даже - тык как фирма не маленькая, одна из первых по стране.

во дела....
и что, Вы хотите сказать, что они так и должны работать? что вся страна прогнулась под сапом и работает только с перемещениями ? Что-то не верится....это ведь действительно неудобно.
неужели САП для нас не может сделать расчет по "остаточному сроку на текущий момент"? Если взять и всем вместе, каждому, кому неудобно работать с перемещениями, выставить по одному сообщению в САП, тогда они задумаются, что пора уже с этим что-то делать.

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

Коллеги, вопрос решен, все работает корректно и главное - по СТАНДАРТУ, без разработок.
Оказалось, что если СПИ меньше года, то модернизацию надо делать обязательно с субномером. Если более года, то все отрабатывает гораздо лучше и красивее.
Т.е. изначально у меня были некорректные тестовые данные. На деле, конечно всякие ситуации бывают, но все же ОС с СПИ менее года не так много бывает.
Настройка в итоге заключалась в создании новой группы видов движения с группой управления периодами "А" и использовании ноты 92925 для корректной работы программы DEPRBONUS.
Кодов амортизации всего 2 - один для БУ и один для НУ, оба со ссылочным значением 23.