Снегопат

Т.е. вы выгружали в ТЗ и далее, накладывали отбор по конкретным контрагентам, вставляли сумму в первую строку, там же "продолжить".
У меня как бы тоже эта таблица практически последняя, именно она уже должна пойти в регистр на запись.
Меня просто смущает, что отбор по ТЗ будет тоже не шибко быстро работать на больших объемах данных. Это в данном пример ключ - "Контрагент", в реальной задаче это тоже ключ по нескольким полям, а у нас в 8-ке нет ИндескированнойТаблицы, которая бы могла построить единый индекс по нескольким полям. Вот этот момент меня и смущает.

Хм, а метод ТаблицаЗначений.Индексы.Добавить("Поле1,Поле2") разве не дает составной индекс?

В одном запросе вроде должно получиться через поиск максимума первого измерения для контрагента, потом поиск максимума второго измерения для сочетания контрагент+найденый максимум первого измерения и т.д. Получим таблицу в которой одна строка для каждого контрагента.
Не знаю насколько такой подход оптимален...

Можно отсортировать таблицу по контрагенту, обойти проверяя что контрагент изменился, накопить таблицу из первых строк.

Ну или через СКД ограничить выборку детальных записей.

Да, наверное дает. Ступил.

Это первое что приходит на ум и об этом я сразу и написал. Но чем больше таких полей, тем больше вложенность, соот-но и производительность падает.
У себя пока так и оставил.

Такой вариант:
делается втРасходыМин (или Макс): группировка по контрагенту, по остальным полям минимум или максимум.
К этой таблице присоединяется втДолги по контрагенту.
Результат соединения присоединяется к втРасходы по всем полям втРасходы