Поле afa_gje - типовая амортизация с нарастающим итогом, должна быть разная.
AFA_GEP - запланированная амортизация, которая рассчитывается в системе.

она не разная....
Почему-то она у меня одня для всех месяцев...

Может действительно у вас одно и тоже значение. Хотя маловероятно. Скорее неправильно передаете berdatum.

Найдите отчет RABEST_ALV01.
И найдите строку

и посмотрите, что идет следом. У нас:


Если у вас также, значит это типовая амортизация с нарастающим итогом.

ДА у нас также, Для 2006 года все показывается нормально, а с 2007 года - которого уже нет в проводнике ОС - суммы выбираются для разных периодов - но все на конец года... (в REPORT zam_os.)

Кстати при запуске этого отчета например на 30.09.2007 сообщение:
Отчетная дата 30.09.2007 для данного анализа не предусмотрена.

Правильно, ЛБД ADA работает с текущим годом, в других годах либо на первое или последнее число. Вам нужна амортизация во всех месяцах любого года?

да! в этом и задача....
Значит попробую через SUBMIT вызывать отчет RASIMU02? может так?

Нет. Этот отчет не дает на все даты.
Только вопрос в том, зачем вам запланированная амортизация по месяцам в будущих годах?

На он может дать амортизацию по месяцам! У меня уже получилось - только загвоздка теперь в MEMORY ID - могу я посмотреть что в нем храниться в определенный момент времени?
Делаю: EXPORT GT_OUTTAB TO MEMORY ID 'zam_assets'., после SUBMIT делаю IMPORT zam_osn FROM MEMORY ID 'zam_assets'.
на в zam_osn ничего не заполняется, хоте перед EXPORT таблица GT_OUTTAB заполнена.

PS. Моделирование амортизации неободимо для автоматического контроля расчета. Бухгалтерия этого не отслеживает, а вводом в эксплуатацию ОС у нас занимаются сотрудники других подразделений...

export ... и import ... должны использовать одно имя таблицы.
Просто непонятно, какой смысл в том, чтобы находить амортизацию на будущие годы по месяцам. В системе SAP нет отчетов для нахождения месячной амортизации, минимальный период для ОС считается 1 год.
Каким образом вы контролируете расчет? Возможно обойтись более простым решением.

У нас в систему был осуществлен первоначальный ввод данных с всякими - разными кодами ОС. Обнаружилось, что многие ОС просто не самортизировали к 01.2005 и соответственно не амортизировали 2005 год... - не правильная загрузка. Сейчас с помощью RASIMU02 проанализировали все ОС, с которыми может быть такая же штука - все поправили. Но проблема еще и в том, что для старых ОС создаются субномера - их тоже надо контролировать... Кстати с RASIMU02 все получилось - получаю амортизацию за все месяца на любой год (до гггг+12)

Что то плохо понял насчет неправильного первоначального ввода ОС с разными кодами.
Насчет стандартных отчетов ошибся, есть неплохой отчеты. Попробуйте RASIMU_ALV, нет ограничений на 12 лет. Показывает амортизацию сразу за все 12 месяцев.

Ну вот RASIMU02 тоже - хороший очень! Тоже 12 лет. Его и использую - все получается!
А насчет кодов - например загрузили ОС - Код амортизации 15% в год, а срок поставили 1 год - и в коде стоит - не амортизировать после окончания срока эксплуатации... Вот такая ......

Не проще поменять базовый метод расчета амортизации?

Может и проще, но это может привести к перерасчету существующих ОС, это не есть хорошо...
Решили старые проверить и не трогать...
А чтобы подобного не получалось - контролировать по-всякому