Всем доброго времени суток:)

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

Необходимо: Провести амортизацию за прошлый год как Убытки прошлых лет на 91* счет.

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

Пришло на ум одно объяснение, единственное пока: т.к. в прошлом году амортизации не было вообще никакой проведено, то система не позволяет ее и корректировать.

Уважаемые коллеги, подтвердите или опровергните мое утверждение по поводу корректировки амортизации за прошлый год.

P.S. Этой транзакцией скорректировали амортизацию у многих ОС, НО у них за прошлый год была хоть какая-то амортизация проведена.

у нас тоже такая проблема. Возникла, когда перенесли ОС на новую карточку и решили поправить амортизацию по НУ, умньшить. Корректировка прошла по строке Write-up, но не в один отчет не попала, на остаточной стоимости не отразиласьникак!
Решили все отсторнировать, и перенос в том числе. В старой карточке поменяли СПИ (увеличили), система перепланировала амортизацию, но неправильно, не на весь установленный срок.
как сделать правильную амортизацию - не понимаю!

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

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

А вот тут уже проблема (не сталкивался, не смогу чтото посоветовать), хотя я видел бухов, которые не заморачивались и делали корректировку текущим годом на затратные счета и все, но можно еще выполнить дополнительную проводку вручную с затратных на 91. В Вашем случае мне вспоминаются слова из какой то книги по внедрению SAP "не пытайтесь программу подстроить под кривой бизнес а наоборот"

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

Я создала пользовательский вид движения 60 группы для начисления внеплановой амортизации на сумму амортизации 2008 года с фиксированным 91 счет.
И создала с ним документ АА в транзакции ABAA.
Но проблема в том, что AFAB по умолчанию использует вид движения 500 - из ракурса V_TABWV_03.
А менять эту настройку каждый раз для прогона внеплановой амортизации за прошлый год - как-то не правильно

у нас смирились, а ручную проводку с затратного делать то же не хотят?

Вручную сделать проводку конечно можно
Но решение не очень красивое....

понятно что не очень, зато деласть могут сами пользователи, а настройки каждый раз менять это ОЧЕНЬ , да и то только соответствующей службой по заявке, так что пусть думают, раз имеют кривой бизнес

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

конкретная ситуация: до января амортизация по ОС уходила на 44* счет;
в 01 месяце ОС переведено в "непроизводственные" (ам-я должна пойти на 91*). в R/3 это отразить забыли. на текущий момент ам-я расчитана за 02 и 03 месяц.
я завел временной интервал, присвоил контроллиногвый заказ. но при попытке сделать повторный рассчет ам-и получаем сообщение: "в повторном прогоне можно выполнить проводки только в периоде 02".

Подобные корректировки проводила не раз. Действительно амортизация при начислении падает на затратные счета и её нужно ручками переносить на 91 счет. Если нет другого варианта для корректировок............я других незнаю. Суммы амортизации бывают разные и иногда они стоят того, чтобы заморочиться независимо от такого насколько это красиво и между прочим не настолько и криво. Аудиторам и налоговикам я думаю по барабану возможности и не возможности ПО в котором ведется учет, им главное достоверность в учете.