Амортизация в бюджетной конфигурации

Здравствуйте!
Имеется следующая проблема:
Бюджетная организаия, бюджетная конфига.
Делаю отчет - Ведомость ОС и НМА.
Неправильно расчитывается норма амортизации
В ОС стаит линейный способ
А расчитывет исходя из остаточного срока
И ОС проверил и Переоценку - все в норме.
Подскажите пожалуйста где еще искать.

Неправильно начисляется амортизация по всем ОС?

"Да, по всем ОС начисляется неправильно.
Толькочто залез в конфигуратор:

НормаАмортизации       = ?(СрокПолезногоИспользованияМ<>0,Окр(100/СрокПолезногоИспользованияМ,2,1),0);  
ОстБалансСтоимОС= Результат.ОС.СтоимостьДляНачисленияАмортизации.Получить(ДатаОтчета);
Если (ОстБалансСтоимОС<>0) Тогда
ОстСрокПолезногоИспользованияМ= Результат.ОС.ОставшийсяСрокПолезногоИспользования.Получить(ДатаОтчета);
ОстНормаАмортизации = ?(ОстСрокПолезногоИспользованияМ<>0,100/ОстСрокПолезногоИспользованияМ,0);
НормаАмортизации    = ?(ОстНормаАмортизации<>0,ОстНормаАмортизации,НормаАмортизации);
       КонецЕсли;


(Прошу прщение за синтаксис - окошко в браюзере маленькое)
Тоесть если есть остаточная стоимось (а куда она денется?) то норма расщитывется исходя из остат срока.
Ничо не понимаю - толи мне пора в отпуск, толи на 1С матюгаться
"

какой релиз?

622

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

День добрый!

Во - первых:
В конфигурации У ОС есть периодические реквизиты "СтоимостьДляНачисленияАмортизации" и "ОставшийсяСрокПолезногоИспользования" (просмотреть их значения можно в справочнике ОС по кнопке "История") которые устанавливаются документами: "Ввод остаков ОС", "Корректировка амортизации" и т.д.. Они-то и влияют на расчет амортизации (по остаточной стоимости и сроку). Для изменения значений реквизитов предназначен документ "Корректировка амортизации".

Во - вторых:
Если все данные по ОС занесены правильно, то у Вас расчет амортизации ведется правильно (внимательно изучите материальную часть).

Удачи.

День добрый всем!
Я не совсем Experimentator, - я его коллега. Уточню проблему..
С периодическими реквизитами худо-бедно разобрались. Действительно там был полный бардак. Но в данном случае, проблему бух-и высветили именно по отчету "Ведомость по ОС и НМА", которая им нравится, но их вводит в заблуждение коэффициент амортизации, показываемый в отчете. Как следует из описанного выше алгоритма (из конфиги), в отчете первоначально и правильно рассчитанный коэф. исправляется (в случае наличия остаточной стоимости) на новый: 100/ОставшийсяСрокЭксплуатации (я перевел название переменной "ОстСрокПолезногоИспользованияМ" в конфиге на понятную "ОставшийсяСрокЭксплуатации"). В результате коэфф. увеличивается обратно-пропорционально оставшемуся сроку. Что это? Ошибка 1С, или очередная охинея ПБУ?
И еще один вопрос..
При расчете факт. срока использования используется очередной хитроумный алгоритм через ...: высчитывается количество дней от дня ввода ОС в эксплуатацию и делится на 30,5 (якобы среднегодовое кол-во дней в месяце). Понятно, что результат часто расходится на +- 1 месяц относительно календарных. Может это и не важно, но с учетом того, что амортизация начисляется все же каждый календарный месяц, при некотором стечении даты ввода и даты составления отчета, результат контрольного рассчета суммы всей начисленной амортизации исходя из срока эксплуатации УКАЗАННОГО в отчете и коэф.амортизации, не сходится с нормой, что опять-таки вводит в заблуждение бух-ов. К тому же, что это за цифра такая: 30,5. При рассчете среднемесячного заработка в НК принято считать что среднегодовое количество дней в месяце 30,4.
Словом, говорим про нанотехнологии, а считать кол-во месяцев, в соответствии с НК, должны по технологии 19, начала 20-го века.
И все же, лазить по законодательству уже больше нет мочи и времени. Так может есть гуру по этим вопросам которые скажут нам, колхозникам: принятый в 1С алгоритм, приведенный выше, - это закон или гениальное изобретение программистов?

С уважением ко всем тем, кто весь этот геморрой понимает и большое спасибо!