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