СП4 Ах3.0 Амортизация

[Arahnid]

Есть ОС. Ввели 30.04.06 , полностью самортизировали 30.04.08. Срок 1 месяц. В группе амортизационной стоит - списание в месяце ввода в экспл. Используем ЛинОст.

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

Понимаю как исправить, но может проблема только в том, что я что-то неправильно настроила?

[TasmanianDevil]

В каком статусе/состоянии пребывало ОС с 30.04.2006 по 31.03.2008, что его не амортизировали ?
По указанной модели ОС какие значения имеют дата начала амортизации и дата последней амортизации ?
При расчете на какую дату идет ругань на попадание в закрытый период ?
Модифицировали ли класс RAssetTableMethodIterator, расчитывающий набор периодов, по которым затем идет расчет сумм для каждой из строк журнала амортизации данного ОС ?

[Arahnid]

Ничего не модифицировали.
Проблема в том, что средство имеет статус открыто, поскольку по одной из трех моделей оно продолжает амортизироваться.
В классе RAssetProposal in method Check* стоит проверка на дату. Если оно попадает и неважно с какой моделью учета (при этом по модели остаточная стоимость 0 и дата последней амортизации стоит правильно), то он все равно ругается. Т.е. это сервисная проблема.

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

[TasmanianDevil]

Рекомендую все-таки отдельно по моделям погонять, чтобы понять, на какую именно матерится и с кем разбираться. Этот метод используется дважды - при вводе значения в диалог и при формировании строки журнала. Ввод значения в диалог отметаем. Формирование строк журнала идет данным класса-итератора периодов амортизации RAssetTableMethodIterator. Он инициализируется там же в RAssetProposal на основании модели учета, ее метода амортизации, дат начала амортизации, последней амортизации, даты операции и наличия консервации у данного ОС для пропуска неамортизируемых периодов. Собственно потому и возник вопрос о модификации этого класса и дат в модели, ибо в случае нулевой остаточной стоимости в периоде, следующем за последним периодом амортизации, набор периодов в нем будет пустой и никаких итераций с формированием и проверками/руганью не должно быть.

P.S. Есть конечно пара фантастических гипотез с одинаковым финалом
1) Игрища с разрядностью EDT сумм RAssetTrans
2) Закачка данных из систем с разрядностью сумм, отличных от разрядности EDT сумм RAssetTrans.
Визуально все в порядке - физически в таблице все не так .
В какой-нибудь из моделей, которую Вы давно считаете самортизированной в уже закрытых периодах, система пропускает к формированию последний кусочек остаточной стоимости, видя что остаточная стоимость ненулевая(но меньше 0.01), запускает проверку на дату, матерится и потом обрубает формирование , видя, что полученная сумма меньше минимальной амортизации (определяется в настройках).
Сам на подобный казус натыкался, но только в складе - 4 знак в кол-ве одной проводки пакостил и некорректно пересчет делался