В продолжение темы: v8: Помогите с оптимизацией;, но что бы не заставлять всех читать что там следующие вопросы:
1. Есть ли некий оптимальны алгоритм который позволяет среди порядка 80000 записей регистра накопления по документу произвести некоторые изменения и сохранить их. Пока вариант только один. Выбрать все по регистратору в ТЗ, сделать в ней изменения и записать.
2. В отличие от рег нак рег расчетов позволяет отбирать не только по регистратору но и по измерению, может переложить на него эту задачу. Кто может справедливо охарактеризовать преимущества и недостатки рег расчета по сравнению с рег накопления.
Заранее спавсибо!

Вообще структура работы с регистром расчетов сильно поменялась по с равнению с компонентой Расчет 7.7. Кто работал и оценит.
Спасибо Волшебнику.

(0) "В отличие от рег нак рег расчетов позволяет отбирать не только по регистратору но и по измерению"

Что-то я не пойму: в регистре накопления действительно нельзя отобрать записи по измерению?

Да именно так. Отбор только через регистратор и ни ни. В этом и проблема. К примеру необходимо исправить несколько записей  в рег накопления, а так как рег накопления работает  только с НаборомЗаписей в котором нужно выставить отбор то приходится перелапачивать все записи.

(4) А как насчет метода менеджера регистра накопления (конкретного регистра) Выбрать() и его параметра отбор?

(4) мы так голову не заморачивали себе - исправления делали добавлением сторно (к тому же видна история изменений прямо в регистре - може сравнивать данные актуальные на разные даты)

Вот я с этим копался, но в отличие от регистра сведений в регистре накопления нет менеджера записи, а есть только регистрнакопленияЗапись, работу котрого по записи и отбору я непойму.
(6) Заморочка не втом чтоб изменить запись. А в том чтобы при необходимости изменить движения по регистру накопления. Бональный пример будем использывать комунальные услуги абонентам. Начисление за услугу основывается на некоторую количественную величину. В начале месяца был произведен расчет и относительно этой величины было сделано начисление. В середине месяца эта величина поменялась. Необходимо чтоб по данному абоненту за конкретную услугу стояло правильное начисление.

(7) доначислить - номер документа N / 2

(8)Я тепя понял, но ты вошел в середину разговора и не понял о чем я. Ты правильно говоришь если б это был перерасчет, но это не перерасчет а начисление за месяц которое может изменяться из за различных данных и ведение переасчетов только будет захломлять базу ненужной информацией. Что было понятно вернусь к примеру в (7).
Начисление за воду абоненту расчитывается от количества жильцов. На начало месяца это расчитанно и оперптор это видит (само сабой там не только вода(стоки, электричество) и не только начисления(оплата, субвенция, перерасчеты)).Абонент приходит и хочет заплотить, но приносит справку что количество жильцов изменилось. Оператор изменяет данные по количеству жильцов и должен получить текущую реальную информацию. Как видишь это далеко не перерасчет.

(8) В любом случае у этих регистров разное назначение.
Где здесь периодические расчеты? Нету. А раз нету, то юзай (8) то бишь, механизм корректировок.

Вся бухгалтерия построена на корректировках. Так что же, регистры бухгалтерии в мусорное ведро?

(10)Как нет переодических расчетов. А начисление по поливу который расчитывается только в поливной сезон, но не будем в дебри я честно не понял о чем вообще выражение.

(9) заплатил жилец 1000 руб. 10го числа, а 15го принес справку что жильцов меньше (получил льготы и т.п.) по новому расекту сумма стала 700 руб. - таким образом пишем в регистр чило (-300) руб. я писал модуль "планирование". там всё работало по этому принципу - записи не переписывались, а дополнялись - быстро и удобно.
что тут не устраивает ?

(11) По-моему нельзя вопрос в (0) сводить к обсуждению конкретной задачи. Я не буду спорить насчет схемы реализации в этом примере.

Может быть замутить тему вроде "Справочник vs Документ" ?

(12)Оно звучит то правильно но меня смущает что к моим 25000 документов по начислению, необходимо будет добовлять еще документы изменений, которые вообщем то ненужны. Начисление на начало месяца 1000, принес справку нужно 700, пишем -300, хотя лучше же перепровести чтоб было 700, ведь зачем хранить данные о начислении в 1000 руб на начало месяца?. А таких лишних записей будет 3000-5000 тысяч в месяц. Как думаешь, стоит пробывать. И можно поподробнее о модуле "планирование" для чего писал, может у меня тоже.

(13) почему "нельзя вопрос в (0) сводить к обсуждению конкретной задачи" ? ведь (0) как и просит о этом !
(+12) еще что хорошо - отвественный сотрудник может увидеть быстрым отчетом ИЗМЕНЕНИЯ (доначисления) - кто, когда, сколько доначислил, по какому документу и т.п.

(13) Да ты прав что мы немного отошли от темы, ограничив её дополнительным условием что как лучше их использовать с большим количеством движений

(14) Типичный выбор между скоростью работы и объемом базы. Если ты ужат в дисковых просторах - экономь, а если контора не поскупилась прикупить "железо" - не тормози !
Модуль "планирование" для одной немаленькой полиграфконторы. Вводится план на месяц обычно за 3-4 месяца, чем ближе к дате Х, тем больше корректировок к нему. Причем надо было хранить ВСЁ - это нужно для понимания ситуации в целом, более точного прогнозирования изменений, потребностей клиентов и т.п.