Друзья, столкнулся со следующей проблемой.
Запускаю ведомость AR02 по очень большому числу карточек РБП (отметка о списании не проставляется, выходят за все года с нулевой стоимостью), несколько показателей (Амортизация нарастающим итогом, Остаточная стоимость) врут кардинально.
Если вернуться к селекции и запустить по конкретному ОС, то все ок.
Может, кто-то сталкивался с таким?

Тема закрыта.
Вижу, что модератор поправил заголовок, но я все же изначально не имел в виду суммирования. Я имел в виду именно неверное определение сумм амортизации и остаточной стоимости для конкретного ОС.
Если вдруг кому интересно, что произошло, коротко поясню.
Пара видов движения имела тип '5' Корректировка амортизации, но была настроена неверно, в результате чего не обновляла соответствующим образом таблицу ANEA.
А вот тут всем ВНИМАНИЕ: в саповском коде недочет.
Инклуд LAFARF40: ищем место CASE TABWG-BWATYP.
WHEN CON_BWATYP_ZUS (тут как раз имеется в виду '5')
MOVE V_ANEA-NAFAV TO U_GANLC-ZUSNA.
MOVE V_ANEA-SAFAV TO U_GANLC-ZUSSA.
MOVE V_ANEA-AAFAV TO U_GANLC-ZUSAA.
MOVE V_ANEA-MAFAV TO U_GANLC-ZUSMA.

Однако t_anea, из которой идет считывание в v_anea, не чистилась при переходе от одного ОС к другому при формировании ведомости. В результате, если для данного ОС (с неверным видом движения) из anea данные не выберутся, то в t_anea останутся записи от старого ОС, а в V_ANEA повторно считается в очередной раз старое значение, вообще не имеющее отношения к нашему ОС.