Ошибка начисления месячной амортизации

[LGray]

Здравствуйте, господа!
Нужна помощь в решении следующей проблемы.
Дано: импортированная в Axapta (3.0 SP4) база данных ОС.
Начисление амортизации идет по линейному методу (от восстановительной стоимости).
Объектов в базе порядка 3000.
Существует проблема при начислении амортизации на "старые" объекты - система в последнем месяце начисляет всю оставшуюся амортизацию в том случае, если на объекте в прошлом был какой-то период консервации, не отраженный в прежней БД
(либо начислена переоценка, а срок не изменился). Амортизация у заказчика считается по формуле:
Амортизация_мес = остаточная_стоимость / срок_использования.

Амортизация в AXapta должна совпадать с амортизацией в прежней БД.

Поясню на примере
Есть объект, введенный 01.07.1966.
Срок использования 480 мес.
Восстановительная стоимость (от которой считается амортизация в Axapta) на 01.05.2005 составляет 335524,00.
Остаточная стоимость на ту же дату - 291867,98
Ситуация: до 01.05.2006 амортизация за месяц начисляется как и положено на сумму 699,
а 01.06.2006 система начисляет скопом всю оставшуюся амортизацию, которая составляет 283479,86 (потому что срок закончился, а оставшуюся стоимость надо куда-то девать).

Вопрос: как избежать этой ситуации с таким "выбросом" в конце, чтобы амортизация продолжала начисляться положенными 699-ми рублями (при том, что сроки использования править НЕЛЬЗЯ).
Метод начисления используется по восстановительной стоимости (по остаточной тоже не катит, так как система берет в качестве делителя не полный срок использования объекта, а оставшийся на дату начисления срок).
У меня, конечно, есть вариант написания своего функционала начисления амортизации, но оочень бы хотелось использовать существующий.

Памажите кто чем может.... Если что - требуйте уточнений и дополнений.

[glibs]

В настройках амортизационных групп параметр Минимальная амортизация корректно установлен?

[glibs]

Дочитал :-)

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

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

[LGray]

Цитата:

Сообщение от glibs

Дочитал :-)

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

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

Да вот и фиг-то, что не я это делал - это делалось в старой программе (которая до Axapta была). Не увеличивать срок - это железное требование бухгалтерии заказчика - они костьми лягут, но не позволят. И изменение срока они с переоценкой не вводили - вот и получилось... Пока обхожусь суррогатными тметодами, но нельзя же, чтобы самостоятельный учет ОС в Axapta так криво велся...

[Михаил Андреев]

Цитата:

Сообщение от LGray

Не увеличивать срок - это железное требование бухгалтерии заказчика - они костьми лягут, но не позволят. И изменение срока они с переоценкой не вводили - вот и получилось...

Типичный пример вменяемости пользователей. Самый простой способ - допилить. Допил несложный. Самый правильный - уволить бухгалтера и взять нормального. Потому что данная ситуация повторится, и не раз. Сами нарушают правила учёта, а потом требуют, чтобы программа сама догадывалась, что же делать.
"Р-р-р" - сказала японская пила...
Хотелось бы почитать их учётную политику. Неужели там такое написано? Сомневаюсь.

[Nick]

Расчет амортизации по БУ или НУ?
Мб эта ситация описана в соответствующей Учетной политике клиента?

[LGray]

Расчет амортизации по БУ, а теперь уже и по НУ, поелику сравняли учеты (это уже точно учетная политика)...
Эх, был бы я тамошним топом, поувольнял бы на фиг полбухгалтерии - но низзя.

Организационные меры я, конечно, попробую, но проблему это не снимет - все равно система будет гаком в последний месяц амортизацию фигачить - застарелый косяк... Если только сроки править, но они на это не пойдут

[Nick]

Цитата:

Сообщение от LGray

Расчет амортизации по БУ, а теперь уже и по НУ, поелику сравняли учеты (это уже точно учетная политика)...
Эх, был бы я тамошним топом, поувольнял бы на фиг полбухгалтерии - но низзя.

Организационные меры я, конечно, попробую, но проблему это не снимет - все равно система будет гаком в последний месяц амортизацию фигачить - застарелый косяк... Если только сроки править, но они на это не пойдут

Не получается сравнять амортизацию БУ = НУ для модернизированных ОС по многим причинам, например, формула расчета по БУ изменилась еще в прошлом году:
НУ - стандартный линейный и что делать с остатком в последний месяц решает каждый главбух сам (много разных мнений),
БУ - именно для исправления похожих ситуаций формулу переделали на
Ам = остаточная стоимость / оставшийся срок

[СибирскийКлещ]

Цитата:

Сообщение от LGray

Амортизация_мес = остаточная_стоимость / срок_использования.

Позвольте сильно усомниться в правильности данной формулы в принципе.
При такой формуле ОС не самортизируется за положенный срок ни при каких значениях. В формуле либо первоначальная стоимость с учетом всех дооценок/изменений стоимости, либо оставшийся срок использования должны стоять. Ради интереса проверьте в Excel - будете весьма удивлены
Ваши 699 рублей вы получите только по формуле первоначальная_стоимость / срок_использования.

Смотрите класс RAssetTableMethod_SL, метод calc() - за линейный метод он отвечает, возможно там есть нечто в коде , что прольет свет на происходящее.

[LGray]

Ну пусть так.
Но делать-то что, дабы пиков не было?
Понятно, что есть вариант написать свое начисление амортизации, но обойтись хочется стандартными средствами, а то у меня какое-то предуюеждение против программирования таких вот вещей...
З.Ы, спасибо за класс