Когда мы пользуемся стандартными классами inventSumDate*, то алгоритм выглядит примерно так:
1. Строим запрос по inventSum+inventDim, группируя по нужному сочетанию аналитик
2. В цикле бежим по результату запроса, вызывая класс inventSumDate* для каждого найденного сочетания аналитик. При этом внутри этого класса, система порождает несколько отдельных запросов к inventSum, inventtrans+inventTransPosting, inventSettlement. При этом каждый запрос, естественно, вызывает достаточно приличные накладные расходы на разбор сервером, построение плана запроса, чтение нескольких страниц из БД и так далее.
InventSumDateEngine работает по другому:
1. Создает запрос по всем номенклатурам и аналитикам в inventSum+inventDim, пишет аналитики и суммы с количествами в inventSumDateTrans
2.Создает аналогичный запрос по inventTrans+inventTransPosting для физических разносок за период, пишет результаты в inventSumDateTrans
3. Аналогично - для финансовых разносок в inventTransPosting за период.
4. Создает запрос для всех коррекций в inventSettlement за период.
5. Группирует и суммирует уже созданные записи в inventSumDateTrans
Потом ты в своем собственном коде должен пробежаться по inventSumDateTrans, напечатать и удалить
Да - там еще есть некое поле с номером сессии или чем-то подобным, чтобы несколько пользователей друг другу не мешали. Вообще - с этим механизмом мне не все понятно. Я, например, так и не понял почему они физические разноски мешают с финансовыми коррекциями. Ну да ладно. А повышение производительности происходит из за того что ты много мелких запросов по каждой номенклатуре и складской аналитике заменяешь на несколько крупных, на которых лучше отыгрывает мощный сервер БД.
Чего сделано в Fast Inventory Reports - не знаю, сам не щупал.