Регистры накопления - центральная концепция платформы 1С:Предприятие. Она кажется интуитивно понятной, но это только вводит в заблуждение. Ситуация усугубляется тем, что найти не то, что хорошее, а хотя бы минимально разумное описание не легко. Обратившись к синтакс-помощнику или сайту 1С (https://v8.1c.ru/platforma/registr-nakopleniya), вы узнаете, что регистры накопления используются для... накопления информации. Здорово! Но вообще-то любая таблица в любой базе данных используется не иначе как для накопления информации. Далее будет дано описание концепции регистров с ее плюсами и минусами, как это видит автор.
Составные части концепции
Концепция регистров накопления 1С состоит из двух частей и одного общего принципа. Первая (и на мой взгляд более важная) часть - Декомпозиция. Вторая часть концепции - Производительность. Объединяющий их принцип - Автоматизм. Рассмотрим их подробнее.
Декомпозиция
Допустим, мы занимаемся созданием учетной системы для склада. Нам надо решить задачу получения остатков товаров на складе. Т.е. создать функцию получения остатков. На первый взгляд все тривиально. Приход на склад увеличивает остаток, а расход уменьшает. Основой для такой функции мог бы служить следующий запрос
ВЫБРАТЬ
ПоступлениеТоваровТовары.Товар КАК Товар,
ПоступлениеТоваровТовары.Количество КАК Количество
ПОМЕСТИТЬ Т1
ИЗ
Документ.ПоступлениеТоваров.Товары КАК ПоступлениеТоваровТовары
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ОтгрузкаТоваровТовары.Товар,
-ОтгрузкаТоваровТовары.Количество
ИЗ
Документ.ОтгрузкаТоваров.Товары КАК ОтгрузкаТоваровТовары
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Т1.Товар КАК Товар,
СУММА(Т1.Количество) КАК Количество
ИЗ
Т1 КАК Т1
СГРУППИРОВАТЬ ПО
Т1.ТоварВ реальных условиях этого будет недостаточно. Очень часто встречается ситуация, когда складской и торговый модуль оказываются чересчур тесно связаны. Большинству потребителей так проще. У них нет четко выделенных документов поступления на склад и расхода со склада. Есть, например, документ РеализацияТоваровИУслуг, который обрабатывается в отделе продаж. А есть также документ ВозвратОтПокупателя. И тот и другой непосредственно влияют на состояние склада. Поэтому, чтобы получить работающую функцию, надо надо будет учесть наличие документов-двойников (Приход-Возврат от покупателя и Расход-Возврат поставщику). Время от времени на складе проводится инвентаризация, в результате которой возникают такие особенные документы, как расход в никуда (Списание) и приход из ниоткуда (Оприходование). Наконец, у нас наверняка будет несколько складов, и как следствие, документ перемещения между складами. Этот документ будет отличаться от всех остальных, тем что будет расходом и приходом одновременно. Можете мысленно представить себе, во что превратится исходный запрос, если учесть все только что сказанное. Даже самые простые задачи довольно быстро переходят границу, за которой их невозможно "окинуть одним взглядом". И разработчикам не остается ничего другого, как пытаться "съесть слона по частям". Но для начала надо "слона" на эти самые части разделить. А это тоже требует усилий совершенно особого рода. По своему опыту разработчика и преподавателя могу сказать, что кому-то это дается с большим трудом, а некоторым не дается вовсе.
А в 1С:Предприятие нам говорят следующее. Вот у вас есть документ ПриобретениеТоваровУслуг. Опишите, что он будет делать с регистром остатков. Описали? Отлично! Теперь переходите к документу РеализацияТоваровУслуг и так далее. Изначально относительно сложная задача распадается на несколько небольших и совсем простых. И происходит это само собой, "автоматом". Это сильно упрощает жизнь разработчикам, особенного новичкам.
У такого подхода есть и отрицательная сторона. Вам надо понять как именно в какой-нибудь конкретной конфигурации формируется остаток на складе. Но это не так-то легко сделать! Функция остатка оказывается "размазанной" по множеству независимых друг от друга программных модулей. Их еще надо собрать вместе. И каким-то образом убедиться, что ничего не пропущено. А это нетривиальная задача и в общем случае требует полного анализа всей конфигурации. Легкость начального создания оборачивается трудностями в дальнейшей поддержке. Это надо иметь ввиду.
Производительность
Сложив все "приходы" и отняв "расходы", мы получим остаток на текущий момент (если быть точным, на момент неопределенного будущего). Но если этих самых "приходов" и "расходов" окажется слишком много, то и вычисление функции остатка займет много времени. Очевидный выход из ситуации, запоминать где-то результат вычисления функции остатков и не вычислять ее каждый раз заново, когда пользователь запрашивает остатки. При появлении в базе нового документа также нет необходимости пересчитывать все сначала. Достаточно просто скорректировать соответствующим образом таблицу актуальных остатков.
Некоторое время назад были нюансы
В седьмой версии 1С:Предприятие и довольно долго в восьмой, кроме актуальных остатков, хранились еще и остатки на каждый месяц. Это вызывало неконтролируемое "распухание" регистра, если на этапе проектирования не продумывали заранее, как будет "закрываться" регистр. В последних версиях платформы по умолчанию хранятся только актуальные остатки. Можно включить хранение дополнительных остатков по периодам, но это мало кто делает. "Закрывать" регистр все еще желательно, но острота проблемы ушла.
В 1С:Предприятие регистр "умеет" это изначально. Не требуется никаких дополнительных усилий для того, чтобы организовать работу с таблицей актуальных остатков. Так же, как и в случае с декомпозицей, все получается "автоматом". И это тоже удобно в первую очередь для новичков. Использование регистров гарантирует, что автоматически будет получена минимально работоспособная версия.
Минусы тут тоже есть, хотя и не такие очевидные, как в первом случае. Автоматическое получение минимальной работоспособности лишает разработчиков стимула вникать глубже в работу учетной системы, анализировать где такое кэширование будет полезно, а где не очень. Быстрое получение актуальных остатков не так уж много где требуется. Чаще всего оно может потребоваться в процессе резервирования товара. А в большинстве прочих случаях мы имеем дело скорее с требованием быстрого получения НЕактуальных остатков и оборотов. Например аналитику надо сравнить продажи за прошлый и позапрошлый месяц. Регистры помогают и тут, но идеальным решением является все-таки вынос кэширования на уровень выше. Имеется ввиду предварительная подготовка отчетов. Этот вариант максимально комфортен для пользователей, потому что в этом случае они получают отчеты моментально.
Заключение
Регистры накопления, как концепция, появились в 1С: Предприятие еще в конце прошлого века, в седьмой версии. И благополучно дожили до наших дней. В целом надо признать эту концепцию очень удачной. 1С:Предприятие стало тем, чем она стала, во многом благодаря этой концепции. Задолго до того, как словосочетания low code и zero code стали популярными, платформа 1С:Предприятие уже предлагала нечто подобное и стала популярной, в том числе, и поэтому.
А всем, кто дочитал статью до этого момента, хочу порекомендовать бесплатный урок от OTUS по проектированию архитектуры систем 1С, на котором будет разобрано какие системы 1С используются на предприятиях, как делаются обмены продуктов 1С со сторонними системами, как правильно проектировать структуру ИТ-систем для максимально комфортной эксплуатации. Узнать об уроке подробнее и зарегистрироваться можно по ссылке ниже.
Подробнее о бесплатном уроке
