Правильно ли я понимаю, что если хочу сделать аналог только оборотного субконто в регистре, то для этого используется "Реквизит" регистра?

для этого делается оборотный регистр

Нужен регистр остатков, и только одно измерение чтобы было оборотным.

(2) регистр остатков и еще один регистр оборотов

в типовых есть регистр остатков ДенежныеСредства, однако по статьям ДДС остатка не получить (только обороты) и поэтому там также есть регистр ДвиженияДенежныхСредств

а в чем смысл? ведь дублирование данных, нагрузка на базу ..

(0) Это будет тормозной аналог. Потому что реквизит - атрибут движений. Итоги по нему не подбиваются. Обычно таки парный оборотный регистр создается.

(0) Всё зависит от задачи. Если твоё оборотное субконто нужно только для информации и будет востребовано редко, то можно и реквизит заюзать, иначе (1).

Просто если у тебя дохринища записей в регистре, а тебе надо дернуть только записи с определенным оборотным субконто, то:

1). Использован реквизит.
Придется выбирать из БД полную таблицу регистра и уже после этого накладывать условие по реквизиту.

2). Использован доп. регистр.
Можно выбрать из БД только записи по нужному субконто.

Как видишь, разница будет ощущаться потом, когда будешь работать с этим оборотным субконто...

(6) нагрузка будет, когда ты попытаешься получить обороты по реквизиту, чего делать нормально нельзя

+(8) это к (5)

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

хм. у меня регистр с шестью измерениями, одно оборотное.
Отчет нужен будет в виде ОСВ : начальный ост, приход, расход, кон. ост.
Приход и расход должен разворачиваться по этому оборотному измерению.

(11) "Приход и расход должен разворачиваться по этому оборотному измерению."
Тогда у тебя один вариант - (1)

(11) А почему не хочешь использовать забалансовый счет для этого, кстати?

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

(13) Тоесть соединение двух таблиц будет работать быстрее, чем выборка по реквизиту?
а СКД нормально работает с реквизитами?

(13) Это даже балансовый счет. Мне субконто не хватает. Три всего. А добавлять не хочу.

Буду дублировать на регистре.

(11) Если производительность твоей ОСВ на регистре остатков для реальных данных тебя устраивает, а измерение - "уточняющее", тогда не парься и делай реквизитом. Если по уму делать, то сложнее. Тогда ВСЕ обороты для ОСВ надо из оборотного регистра брать, а из остаточного - только остатки.
(14) Какой еще "агрегат за весь период для остатков", если они  только для оборотных регистров?

(18).2 эмуляция остатков через обороты за весь период

(16) Ну, началось...
Номер счета и названия субконто в студию...

(20) это не типовая конфа.

(15) Как тебе быстрее:

1). На тебя вываливают два камаза апельсинов и после этого ты выбираешь из них зеленые и их выкидываешь.

2). Тебе дают сразу все зеленые апельсины и ты их выкидываешь.

(21) Не важно.

(19) Думаешь, самый хитрый? А руками не щупал, но вроде ж агрегаты только по запросу актуализируются. Т.е. для OLTP не канает. А для целей быстрого анализа на таких серьезных данных, где имеет смысл костылями заморачиваться, лучше уж с честным OLAP заморочиться.

"А руками не щупал" = "Я руками не щупал"

(24) вот и я не щупал, а инфы мало

Ну, щупать не щупал, но читал я внимательно. И сделал вывод, что ноги моей там не будет :) Это недо-OLAP. Со всеми его недостатками, но при этом со всех сторон "недо".

(27) если внимательно, то как интерпретировать фразу http://v8.1c.ru/overview/Term_000000564.htm "При этом система с одной стороны использует накопленные агрегированные данные, а с другой стороны всегда обеспечивает актуальность получаемых отчетов."

(28) Думаю, в случае когда агрегаты считаешь за закрытые периоды. Тогда открытый по движениям считаться будет. Если бы была такая красота, как ты предполагаешь, то нафиг нужны обычные оборотные регистры?

Для хорошей отчетности нужно МНОГО агрегатов. Обновлять их все он-лайн - сам понимаешь. Одновременно получить все преимущества OLTP и OLAP не получится.

Единственное нормальное "быстрое" внедрение агрегатов я вижу так - первичка мигрирует в аналитическую базу, но делает там движения только по нужным оборотным регистрам с агрегатами. Которые считаются по подходящим регламентам.
Остатки ессно придется считать как обороты за весь период. Как и в OLAP. Только в OLAP это реально быстро, а насколько быстро тут получится - х.з. Если разработчики не натупили, то должно быть приемлемо.

(31) ну итоги же обновляются автоматом, почему агрегаты не должны? вот я не нашел необходимости именно ручного обновления агрегатов.

(32) См. (30)
Производительность.

Проще говоря, обычный оборотный регистр - это один агрегат.

(33) про производительность я тебе могу сказать. мне в наследство досталась база, в которой учет остатков по серийным номерам велся в оборотном регистре через запрос за весь период. Потому что для таблицы итогов в файловой базе не хватало места. Пришлось залепить заляпуху в виде РС, который эмулировал таблицу текущих итогов, но тогда еще агрегатов не было. сразу скажу - перевод в регистр остатков и сдвиг периода рассчитанных итогов и оставления только текущих итогов также падал по переполнению внутренней таблицы на этапе перевода в регистр остатков.

(35)+ тогда агрегаты, если они работают как итоги регистров, только по произвольным наборам данных - решили бы проблему.

наборам = разрезам

(35) Ну, твоя экзотическая балалайка фактические расклады с агрегатами никак не меняет.
Если бы 1С запили автоматический расчет агрегатов, тогда "обычные" оборотные регистры можно было бы смело списывать как устаревший механизм типа того же построителя отчетов.