Уважаемые коллеги!
Как правило, операции по РБП автоматизируют с помощью двух основных инструментов:
- долгосрочные проводки в FI
- средствами FI-AA

Мы склоняемся делать это с помощью FI-AA. Пока проблема только одна. При списании данных расходов затратных счетов существует окло 15 штук. Стандартно затратрый счет (например, по списанию расходов амортизации) прописывается на уровне класса.
Уж очень не хочется колбасить 15 классов. Возможно, есть какое-то более оптимальное решение?
Буду благодарна любой помощи.

Насколько не хочется колбасить 15 классов? )

на самом деле 1 класс - 1 средство выбора счета - 1 набор счет учета:счет амортизации:счет затрат

Можно сделать класс 1, и на этапе амортизации делать замену..

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

так что вопрос остается - или 15 классов и стандарт, или 1 и жуткого рода замещение

Использем несколько классов на каждый затратный счет уже больше года. Это помогло решить многие проблемы возникающие в процессе работы и формирования отчетов по РБП.

Поделитесь опытом, плиз, кто ведет в АМ эти расходы будущих периодов.
1. Есть такие ОС, у которых срок использования, например, 340 дней.
В области оценки же можно поставить только целое количество месяцев.
2.Как загрузить остатки:
- если по остаточной стоимости и с оставшемся сроком использования, то возникакют проблемы по таким объектам, у которых завершение амортизации в середине месяца;
- если с накопленным износом, то почему-то амортизация считается неправильно.

Проблема с расчетом по дням действительно существует, если срок использования не равен целому количеству месяцев. В таких случаях у нас не получилось рассчитать сумму списания точно.

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

А кто-нибудь создавал пользовательский метод? Поделитесь опытом.

В транзакции CMOD добавляете в свой проект расширение ARAR0002,
в разделе компоненты активизируете компонент EXIT_SAPLAFAR_002, создаёте код для include ZXAFAU02. Include вызывается в ф. EXIT_SAPLAFAR_002, поэтому в нём можно использовать информацию, передаваемую через параметры этой ф-ции. Среди важных параметров обязательно надо рассмотреть следующие: I_BEZWRT - сумма, которую надо самортизировать, I_ANLB - параметры амортизации, в т.ч. начало амортизации и код амортизации, I_AFABE,
T_ANEP (в т.ч T_ANEP-bwasl).
Функция вызывается, чтобы рассчитать, какую часть суммы I_BEZWRT надо самортизировать за период. Длительность периода - I_AFAP-PERAFAGW (если в настройке кода амортизации указали, что расчёт по дням, то в I_AFAP-PERAFAGW будут дни). Начало периода определяется в зависимости от операции, например, для выбытия или оприх зад числом это может быть I_ANLB-AFABG, для поступления или при редактировании карточки - t_anep-bzdat. Рассчитанная в соответствии с вашим алгоритмом списываемая сумма возвращается через параметр E_AFABTR.

Среди других парметров интересны i_afap-rperbeg - начало периода, i_afap-rperend - конец периода, но не уверен, что ими можно воспользоваться при операции перерасчёта амортизации.

Поставьте break в include, и исследуйте содержимое парметров при разных операциях: создании/редактировании карточки, поступлении, оприход задним числом, при входе в проводник, при расчёте амортизации, при перепланировании амортизации.

Спасибо, попробую

По вопросу первого оратора готов сообщить следующее:
1. Можно использовать базовый принцип контроллинга, что статистический объект "младше" реального.
2. Создать статистические объекты заказы и, соответственно, МВЗ для каждого случая и заполнять их в карточках. Проводки пойдут на реальные и на статистические объекты, причем сумма обновится на реальном объекте.
3. Поскольку статобъект все равно попадает в FI-проводку, то становится возможным замещением.
4. Пишем замещение по соответствию статобъекта и нужного нам счета и система его ловко начинает подменять, не глядя в настройки счетов расходов по классам.

Вот такой могу вариант предложить...

Не понял, помогло или не помогло?

коллеги , подскажите, а как именно вы пытались объяснить системе, что ту или иную РБП-ку надо амортизировать скажем 25 или 55 дней. ведь на закладке оценка можно либо годы либо месяцы толкьо вставить, чтоб система считала амортизацию. а как быть с днями?
Для ОС как настроить амортизацию по дням понятно . в стандарте в коде амортизации проставляем галку расчет по дням и в тот момент, когда ОС выбыло система прекращает считать амортизацию. И расчитывает амортизацию по дням. и все идет правильно.
А что делать с РБП?

я так понимаю тут только АБАП может помочь?

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

спасибо. мы тоже решили примерно атак сделать. только не картчокукорежить, а натсроечную таблицу создать. ну и сооьветсвенно бзать новые BAPi,рекомендованные сапом, т.к afar002 в 6.0 не рабоатет((((

Коллеги, приветствую!
Простите за некропостинг, но что сейчас используют вместо EXIT_SAPLAFAR_002 ( ZXAFAU02 )?