Перешли на Нав 5.0. Очень медленно calcsums :(

[rmv]

Немного теории:
В Пятерке поменяли механизм работы с сифтами - теперь вместо таблиц и кода на триггерах таблиц используется индексированные представления.
К сожалению, это положительное новшество еще больше увеличило различия между Native DB и SQL версией. Ключ, идеально работающей в NativeDB может сильно тормозить работу SQL версии и наоборот. На двух стульях усидеть тяжело, и, судя по 5.0, MS не спешит пересаживаться с Native DB .
Поясню на примере ключа:
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date" c sumindexfield "Outstanding Qty. (Base)" и
галками MaintainSiftIndex на каждой из комбинаций:
Type,"No."
Type,"No.","Variant Code"
Type,"No.","Variant Code","Drop Shipment"
Type,"No.","Variant Code","Drop Shipment","Location Code"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date"

В Native DB значение поля "Outstanding Qty. (Base)" физически хранится вместе с индексом.
В SQL версии до 5.0 предрасчитанные значения хранятся в отдельной таблице причем на каждую комбинацию. Для вашего кода в связанной таблице существует только одна запись и выборка из нее получается практически мгновенной.
В SQL версии начиная с 5.0 существует одно индексированное представление (то что оно индексированная - тоже нужно проверить) c полями
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date", SumIndexField1, .. SumIndexFieldN и первичным ключом Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date". Запрос, выполняемый при вызове кода rSalesLine2.CALCSUMS("Outstanding Qty. (Base)") будем выглядеть как:
select sum(["Outstanding Qty. (Base)"]) from IndexView where ....(перечесление фильтров).
Скорость его работы будет напрямую зависеть от количества наложенных фильтров, количества записей в таблице и селективности ключа.

В вашем случае я бы сделал:
1. Проверил что сифты действительно лежат в индексированных представлениях (возможно индексированные view отключены в настройках сервера).
2. Проанализировал запросы и селективность используемых ключей. Общие правила: Длинные ключи - зло. Поля, часто используемые в расчете сифтов должны быть передвинуты в начало ключа (к примеру болтающийся в конце ключа Posting Date не прибавит скорости работы отчетам по оборачиваемости). Для книг операций запрещается указывать поле Entry No. во вторичном ключе, если в нем определены SumIndexFields. Ключ должен строится по принципу наибольшей селективности (в общем случае разумнее использовать ключ "Document Type", "Document No." нежели "Document No.", "Document Type").