Для простоты предположим что каждый месяц у нас сто тысяч движений и ни одно не закрывается - только приходы по уникальным ключам.
Тогда в первый месяц имеем 100 000 остатков, во второй 200 000 остатков, но сама таблица будет 300 000 записей. и т.д.

проще спросить однако...

(0) как то так

Мусье пытается изобрести формулу суммы арифметической прогрессии?
опоздал лет на 800 примерно.
но похвально.

(3) Он о том, что не в курсе относительно фактического механизма хранения остатков, и подозревает что там могут быть ещё некие производные записи, зависящие от предыдущих.
Я бы просто поставил эксперимент и вывел эмпирическую формулу)

А если не равномерно? Первый месяц 100 000, второй 75 000, третий 34 000, четвертый 130 000?

Арифметическая прогрессия — это числовая последовательность a1, a2,..., an,... для которой для каждого натурального n выполняется равенство:
an+1= an + d, где d — это разность арифметической прогрессии.

Описать словами эту формулу можно так: каждый член арифметической прогрессии равен предыдущему, сложенному с одним и тем же числом d.

"с одним и тем же числом d"... Вот в регистрах же оно не одно и то же.

(4) Если остатки не закрылись они переносятся на следующий период.

Ни в какой прогрессии. Просто обычный числовой ряд и его сумма.

Все же название ему не помешает.
Ряд незакрытых остатков 1С. Звучит?

Ряд нарастающих остатков 1С. Так лучше

Ряд Прохожего

(13) И в отличие от прочих рядов, которые исследуют на сходимость, для этого важнее определить проходимость.

Ряд Проходимца

Пришёл программист-проходимец, внёс изменения в приход, не сделал расход по измерениям. По регистру начал строиться Ряд Проходимца

Мне сейчас написали в скайп:

Остатки закрываются (и проверяются) по:
- "Поставке", без учёта измерений "Проформа" и "ЗаказКлиента"
- по "Проформа" и "ЗаказКлиента", без учёта измерения "Поставка"

Это все в пределах одного регистра. Измерения в записях документы пишут в любых комбинациях, лишь бы по отдельным измерениям сошлося.
То есть мультирегистр в одном, гениальное решение. Главное - это ресурсы, а не измерения. Но остатки 1С накапливаются...
Вот думаю как оно называется.
(13) Мопед не мой.

>> лишь бы по отдельным измерениям сошлося.
>> Главное - это ресурсы, а не измерения.

Чувствуете противоречие?

Нет....

(21) Ну так вот. Главное это измерения, потому что регистр накопления представляет собой гиперкуб с измерениями. На пересечении измерений есть ячейки, которые показывают значения, это ресурсы. В таблице остатков хранятся НЕНУЛЕВЫЕ значения. Так что чем больше нестыковок по измерениям, тем больше будет таких ненулевых ресурсов.

А если применить сюда квантовую теорию, то мир - это гиперкуб, в котором ненулевые остатки только множатся? Ведь вероятность того что они закроются ничтожна. Когда хранящий нас сервер переполнится остатками и не сможет открыть новый период время кончится?

Просто эти ребята написали очень реалистичную модель учета...

(23) Это уже нас не касается. Занимайтесь регистрами и не лезьте в инфраструктуру мультивселенной.

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

Кстати, а как 1С работает с датами до РХ? Например, ДР Юлия Цезаря )

(17) >>Остатки закрываются (и проверяются) по:
- "Поставке", без учёта измерений "Проформа" и "ЗаказКлиента"
- по "Проформа" и "ЗаказКлиента", без учёта измерения "Поставка"

Это логическая ошибка в проектировании. Остатки должны закрываться по всем измерениям. Классически, судя по описанию - тебе нужно этот регистр расшить на несколько, сократив итоговое количество измерений первого монстра. И по каждому регистру закрывать отдельно.

Сходу и так ясно, что Заказ клиента (продажа) и поставка (закупка) сворганенное на одном регистре - будет закрываться с трудом, хотя такая схема есть в типовом решении, но она построена конечно не на одном регистре, т.е. заказ клиент формирует потребность, и конечно, он ничего не знает по поставках. В тоже время, поставка уже знает, какие заказы клиента она может закрыть.

(17) >> мультирегистр в одном, гениальное решение.

Говно это, а не решение. Авторы его придумавшие - идиоты, не понимающие особенности того инструмента, с которым работают - платформы 1С.

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

(27) Тогда не было дат. Там были "годы до нашей эры" в виде числа.

(30) Гай Ю́лий Це́зарь, 12 июля 100 года до н. э. — 15 марта 44 года до н. э.

(31) Вот храни отдельно число, месяц и год отрицательным числом

(24) >>Просто эти ребята написали очень реалистичную модель учета...

Нет. Это наглядный ответ всем хейтерам экзамена Специалиста по платформе. Если у тебя есть остаточный регистр накопления, он должен закрываться в ноль по всем измерениям, иначе оценка неуд. Сохрани себе эту ветку и показывай её всем, кто еще задает вопросы, какого хрена 1С заставляет сдавать этот экзамен. Вот поэтому, чтоб таких ошибок не было, и заставляет. Т.к. ты когда готовишься, у тебя на подкорках это где-то записывается и ты сразу думаешь, при добавлении нового измерения, а ты закрыть то его сможешь?

(32) Хотел предложить дату и реквизит "знак даты", то тогда упираемся в 4000-й год до нашей эры. Ваше решение универсальнее.

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

(35) И как такое решение можно назвать "гениальным"?

Ничего сложного в разделении одного такого регистра на два нет.
Если остатки совсем некорректные, то внести остатки в новые регистры вручную на основании инвентаризации, например.

(33) если понимаешь, как устроены регистры - никакой экзамен не нужен.  ну а если не понимаешь, то только зубрить, да...
(35) ничего удивительного. Кстати, "в плюс" регистр крутят с полным набором измерений, или тоже с кусочным
?

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

(38) Зачем схлопывать? я просто хотел знать как называется по научному процесс разрастания подобного катаклизма будучи пущенным на самотек.

https://infostart.ru/1c/articles/1061227/

формула более сложная но близко к аифметической

(41) Благодарю

например даже если регистр закрывается в 0 но постоянно новая номенклатура создается
то в текущих итогах будет по всей номенклатуре 0-вые записи с кол-во=0
которые удалятся после пересчета итогов

(43) Не знал... Круто.

(39) хаос? увеличение энтропии? или не настолько научно?

(45) не, см (25)

(45) (39) Это называется бардак

(48) ну он сам написал "как называется по научному процесс".
бардак - это, наверно, больше по-бытовому

я тупой и жадный. И я с вами не согласный.

(43) Это касается только текущих итогов и итогов в том месяце, когда остаток по набору измерений вышел в ноль.
В итогах за следующий месяц записей с нулевым остатком по этому набору измерений уже не будет.

То есть для примера.
В январе пришло 10 единиц Товара1.
В таблице текущих итогов и таблице итогов за январь появится запись "Товар1, 10".
В этом же январе после выбытия (списания) всех 10 единиц Товара1 в таблице текущих итогов и таблице итогов за январь появится запись "Товар1, 0".
Если в феврале никаких движений по Товару1 не будет, то в таблице итогов за февраль и за все последующие периоды записи "Товар1, 0" уже не будет.

В статье по ссылке из (40) в момент приходования товаров на 01.01.2013г. уже были рассчитанные итоги на январь, февраль, март, апрель, май и июнь. Поэтому добавились записи с итогом по "Товар №1" в каждый из этих месяцев. После списания товара в апреле остались записи с нулевым итогом в мае и июне. Но если бы на момент списания итоги за май и июнь ещё не были бы рассчитаны, а рассчитывались бы позже, то этих записей с нулевым остатком там не было бы.
И как заметил автор статьи, в любом случае при пересчете итогов такие рудиментные записи удаляются.
Видимо разработчики регистров исходили из того, что большинство движений делается в текущем периоде (НЕ в прошлых) и итоги за текущий период ещё не рассчитаны. В таком сценарии записи с нулевым остатком в таблице итогов не возникают. Только в текущих итогах (на 1 ноября 3999 года).

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

Проблемы могут ещё возникнуть, если остатки выйдут за границы размерности ресурсов. Что является нормой, когда вы бесконечно приходуете по одному набору измерений, а списываете - по другому.
Если, например, у ресурса "Количество" установлен тип "число" длиной 15, точность 2, то при попытке записать туда число длиной в 16 знаков можно получить неожиданный результат. Какая-то СУБД может ругнуться, а какая-то запишет некорректный итог.

(51) именно так. Гариком опять слышал звук колокола, но местонахождение оного не локализовал...