1с регистры накопления что это
Регистр накопления
Регистры накопления — это прикладные объекты конфигурации. Они составляют основу механизма учета движения средств (финансов, товаров, материалов и т. д.), который позволяет автоматизировать такие направления, как складской учет, взаиморасчеты, планирование.
Регистр накопления образует многомерную систему измерений и позволяет «накапливать» числовые данные в разрезе нескольких измерений. Например, в таком регистре можно накапливать информацию об остатках товаров в разрезе номенклатуры и склада, или информацию об объемах продаж в разрезе номенклатуры и подразделения компании.
Структура
Информация в регистре накопления хранится в виде записей, каждая из которых содержит значения измерений и соответствующие им значения ресурсов.
Измерения регистра описывают разрезы, в которых хранится информация, а в ресурсах регистра накапливаются нужные числовые данные. Например, для регистра ТоварныеЗапасы, который имеет следующую структуру:
записи, производящие изменение ресурсов регистра в базе данных, будут выглядеть следующим образом:
Поскольку регистр накопления служит для накопления числовых значений, каждая запись выполняет изменение хранимых ресурсов — движение. Движения, в общем случае, могут либо добавлять некоторые приращения к хранимым ресурсам, либо отнимать их. Если должно выполняться увеличение хранимых ресурсов, — такое движение называется движением прихода («+»), если уменьшение хранимых ресурсов — движением расхода («-»).
Вместе с каждой записью, находящейся в регистре накопления, можно хранить дополнительную произвольную информацию. Для этого служат реквизиты регистра накопления.
Связь с регистратором
Изменение состояния регистра накопления происходит, как правило, при проведении документа. Поэтому каждая запись регистра связана с определенным документом — регистратором, номером строки этого документа, и датой — периодом:
В общем случае значение поле Период может не совпадать с датой документа. Например, документ План продаж может внести в регистр накопления записи о предполагаемых продажах компании несколькими разными датами.
Состав документов, которые могут создавать записи в регистре накопления, задается разработчиком в процессе создания прикладного решения:
Конструктор движений
Алгоритмы, по которым формируются записи в регистре, описываются средствами встроенного языка в процедурах соответствующих документов. Система содержит конструктор движений, который помогает разработчику создавать алгоритмы проведения документа. Подробнее…
Уникальность записей
Система обеспечивает контроль уникальности записей, хранящихся в регистре накопления. Благодаря этому в регистре накоплений не может находиться двух записей, относящихся к одной и той же строке одного и того же документа.
Регистры остатков и регистры оборотов
Существует два вида регистров накопления: регистры накопления остатков и регистры накопления оборотов. Регистр накопления остатков позволяет хранить как итоговые значения ресурсов — остатки, так и изменения этих ресурсов — обороты. Регистр накопления оборотов является более «специализированным» видом регистра накопления и позволяет хранить только изменения ресурсов — обороты.
Существование регистра накопления оборотов связано с тем, что при автоматизации экономической деятельности существует большое количество ситуаций, когда требуется накапливать только обороты, а значения остатков не имеют смысла. Типичным примером использования регистра накопления оборотов является регистр Выручка и себестоимость продаж, хранящий информацию об объемах продаж:
Поскольку регистр накопления оборотов не накапливает остатки ресурсов, для него не имеет смысла «направление» движения ресурсов (приход или расход); накапливается только величина изменения ресурсов. Поэтому все записи регистра накопления оборотов отмечены одинаковыми пиктограммами.
Агрегаты
Для оборотных регистров накопления платформа поддерживает специальный механизм агрегатов, который позволяет значительно ускорить получение данных из регистров, содержащих большое количество записей — сотни тысяч и миллионы записей. Подробнее…
Форма списка и форма набора записей
Для того чтобы пользователь мог просматривать данные, содержащиеся в регистре накопления, система поддерживает форму представления регистра накопления — форму списка. Она позволяет выполнять сортировку и отбор отображаемой информации по нескольким критериям.
Система может автоматически генерировать эту форму. Наряду с этим разработчик имеет возможность создать собственные формы, которые система будет использовать вместо формы умолчанию, в том числе и форму набора записей, которая позволяет добавлять, изменять и удалять записи регистра сведений.
Регистры накопления 1С и их использование
Задача любой учетной системы — хранение и оперативное отображение информации для пользователя, т.е. цель проектирования любой системы — оперативно предоставить пользователю отчет. С помощью полученных данных, как правило, принимаются управленческие решения на предприятиях.
Предположим, что у нас есть 1000 разных документов: поступление товаров, списание, возврат, продажа и т.д. И каждый из документов изменяет количество определенного товара на складе. Чтобы получить информацию о текущем количестве на складе, необходимо перебрать все документы: какие-то увеличивают количество товара, какие-то уменьшают, какие-то могут и увеличивать, и уменьшать. А если необходимо учитывать еще и склад, организацию. Такая система очень ресурсоёмкая.
Для упрощения данного процесса разработчики 1С придумали особые объекты конфигурации. Используются они для удобства хранения и получения информации, в 1С 8.3 используются всевозможные регистры, в данной статье речь пойдет именно про Регистры накопления.
Что же такое регистр накопления в 1С 8?
Сам регистр накопления представляет собой таблицу с информацией, в которой собраны все движения (поступления/списания или обороты) определенных документов. Рассмотрим, как выглядит таблица движения, на примере типового регистра накопления «Товары на складах» в конфигурации «Управление торговлей 10.3»:
Здесь мы видим, что документы 1C «Реализации» уменьшают количество определенного товара в определенном месте хранения, а документы поступления, наоборот, увеличивают количество. В итоге мы получаем общую картину, в которой отчетливо видно, что, когда и в каком количестве поступило (было списано) по учету. По такой таблице уже гораздо удобнее строить отчет.
Регистр накопления в конфигураторе
Что же такое регистр накопления с точки зрения разработки конфигурации? Начнем, пожалуй, с рассмотрения полей регистра накопления в конфигураторе:
У регистра накопления есть Измерения, Ресурсы, Реквизиты и Стандартные реквизиты.
Рассмотрим сначала стандартные реквизиты регистра накопления:
Измерения регистра накопления
Измерение — это разрез, в котором ведется учёт. На вышеприведенном примере разрезом учета являются: склад, номенклатура, характеристика номенклатуры, серия номенклатуры, качество. Т.е задав интересующие нас измерения, мы можем в любой момент получить количество — ресурс. В разрезе разных измерений в дальнейшем, например, можно получать остатки на определенную дату.
Ресурс регистра накопления
Ресурс — это числовое поле, в котором хранится информация в разрезе измерений, о которых писали выше.
Иначе взаимодействия измерений/ресурсов можно схематично изобразить как систему координат:
Два измерения — абсцисса и ордината системы координат, т.е. на данном примере измерения это склад и номенклатура. На пересечении измерений мы можем получить количество — ресурс. Например, на «основном» складе товара «карандаш» в наличии 1 штука.
Реквизиты регистра накопления 1C
Реквизиты регистры накопления несут в себе роль «комментария» или дополнительной информации, в разрезе измерений нельзя получить остатки/обороты. Используются достаточно редко.
Виды регистра накопления
Существует два вида регистра накопления — обороты и остатки.
Если целью регистра накопления не является получение остатков, обязательно нужно использовать вид регистра накопления — обороты. Типичный пример использования оборотного регистра — регистрация объема продаж. В данном случае нам нужно знать только, какие продажи были за определенный период времени, остатки в данном случае не имеют смысла.
Если же среди целей использования регистра накопления — получение остатков на определенный период, нам необходим регистр с видом остатки. Такой тип позволяет получать как остатки, так и обороты. Для такого регистра система автоматически рассчитывает остатки. Пример «остаточного» регистра — товары на складах, деньги в кассе.
Использование вида регистра остатки, где можно обойтись оборотами, считается грубой ошибкой при проектировании регистра накопления с точки зрения производительности системы.
В зависимости от вида регистра система будет создавать разные виртуальные таблицы для регистра накопления. Виртуальная таблица – быстрый способ получения профильной информации из регистров.
Для регистра накопления это:
Для разработчика решения данные берутся из одной (виртуальной) таблицы, но на самом деле платформа 1С берёт из множества таблиц, преобразовывая их в нужных вид.
Правильное проектирование регистров накопления
Регистры накопления необходимо проектировать из необходимых отчетов. Самое трудное в системе 1С 8.3 — правильно хранить информацию, чтобы её в любой момент было легко получить.
Среди особенностей проектирования регистра следует отметить необходимость правильно расставлять по порядку измерения в регистре. Выше всего необходимо ставить измерения, которые будут чаще запрашиваться в системе.
Индексация измерений регистра накопления
У измерений регистра накопления имеется свойство — «индексировать». Это свойство необходимо устанавливать на измерения в тех случаях, когда по измерению планируется часто накладывать отборы при получении данных и данное измерение может иметь большое количество вариантов значения.
Например, регистр «ТоварыНаСкладах», измерения — «Склад, Номенклатура», ресурс — «Количество».
Правильнее проиндексировать «Номенклатуру», а поле»Склад» индексировать не стоит, потому как количество складов в системе, как правило, не существенное.
Другие статьи по 1С:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Регистры накопления. Виртуальные таблицы. Часть №1: Обороты
О регистрах накопления
В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.
Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.
Больше года назад сайт был закрыт. Некоторые из его материалов будут реанимированы на Инфостарт.
Конкретно в этой статье речь идет о виртуальной таблице «Обороты» регистров накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.
Виртуальные таблицы
В статье «Регистры накопления. Структура хранения в базе данных» мы рассматривали таблицы, которые использует платформа для хранения движений в регистрах накопления, а также его итоговых оборотов или остатков в зависимости от вида регистра («Остатки» или «Обороты»). Также были подробно рассмотрены действия платформы с таблицами остатков и оборотов при записи движений в регистр.
Сегодня в статье проанализируем SQL-запросы, формируемые платформой, при обращении к виртуальным таблицам регистра. Напомню, что у регистров накопления существует всего три виртуальных таблицы:
Как мы видим, кроме физической таблицы движений, для которой в базе данных создается отдельная таблица, также имеются виртуальные таблицы. Всего их три:
Последние две становятся доступными только если вид регистра установлен как «Остатки».
Главное отличие виртуальных таблиц от физических: виртуальные таблицы не хранятся непосредственно в базе данных. При выборке данных из виртуальной таблицы платформа формирует некоторый запрос в зависимости от переданных параметров, который может получать записи из двух и более таблиц для формирования конечного результата.
Далее в статье проанализируем SQL-запросы платформы 1С:Предприятие 8.2 при обращении к виртуальной таблицам. При этом будем выполнять запросы при различных комбинациях параметров.
Сторона СУБД
Начнем анализ с виртуальной таблицы «Обороты», так как она присутствует вне зависимости от вида регистра.
Виртуальная таблица «Обороты»
Виртуальная таблица «Обороты» есть, как у регистра накопления с видом «Обороты», так и с видом «Остатки». Рассмотрим оба варианта. Начнем с последнего.
Вид регистра «Остатки»
Посмотрим состав полей таблицы оборотов на примере регистра «ОстаткиНоменклатуры».
В нем содержатся поля каждого из измерений, а также поля «Приход», «Расход» и «Оборот» для каждого из ресурсов в регистре. В нашем случае у нас два измерения («Номенклатура» и «Склад»), а также три поля «КоличествоПриход», «КоличествоРасход» и «КоличестоОборот».
В зависимости от установленного параметра «Периодичность» в состав доступных полей вирт. таблицы будут добавляться соответствующие периоды («ПериодДень», «ПериодМесяц» и т.д.).
Теперь напишем простой запрос для получения оборотов по номенклатуре за период. В параметрах виртуальной таблицы установим поля «НачалоПериода» и «КонецПериода», а в условия добавим отбор по складу «Склад №1». При выполнении запроса платформа сформирует два SQL-запроса к базе данных. Первый запрос получает настройки регистра накопления:
Используя эти настройки, платформа формирует SQL-запрос непосредственно на получение оборотов. Вот так выглядит SQL-запрос платформы для получения оборотов:
Старался подробно разобрать весь запрос. Если будут непонятные моменты, то прошу в комментарии. Исходный текст запроса на языке 1С:Предприятия выглядит следующим образом:
В случае, если для виртуальной таблицы также устанавливается параметр «Периодичность», например, в значение «Месяц», то SQL-запрос немного видоизменится:
Если в виртуальной таблице периодичность установлена «Авто», то в SQL-запросе будут содержаться поля периода для каждой из получаемой в запросе периодичности («День», «Месяц», «Год» и т.д.). Причина, по которой платформа хранит значения периода с увеличением части даты «Год» на 2000 лет мне не известна. Если кто из читателей подскажет, буду благодарен.
Мы с Вами рассмотрели SQL-запросы платформы при работе с виртуальной таблицей «Обороты» регистра накопления с видом «Остатки». Как мы видим, виртуальная таблица «Обороты» в этом случае берет данные из таблицы движений регистра. Даже, если обороты в запросе получаются за несколько месяцев, необходимые данные будут также формироваться по таблице движений без использования каких-либо сохраненных ранее итогов. И это понятно, регистр накопления с видом «Остатки» предназначен для учета остатков, а не оборотов. Далее мы увидим, почему для решения задач учета оборотов лучше использовать соответствующий вид регистра накопления.
Вид регистра «Обороты»
Виртуальная таблица «Обороты» включает в себя поля для каждого из измерений регистра, а также по одному полю на каждый ресурс. Для оборотного регистра «ДвиженияНоменклатуры» из тестовой конфигурации состав полей таблицы следующий:
Как и в предыдущем случае, в зависимости от параметра «Периодичность» в составе доступных полей появятся соответствующие периоды.
И так, выполним несколько запросов к таблице «Обороты» и проанализируем SQL-запросы платформы. Первый запрос на языке запросов платформы:
Первым делом платформа 1С:Предприятие получит настройки регистра накопления, к которому выполняется запрос. Запрос будет идентичный рассматриваемому ранее примеру, пойдем дальше. Сформированный платформой SQL-запрос тогда будет такой:
К комментариям в приведенном тексте добавлю, что вне зависимости от значений параметров «НачалоПериода» и «КонецПериода» запрос пытается получить данные и из итоговых таблиц, и из таблицы движений регистра.
Если в запросе на языке платформы мы добавим использование параметра «Периодичность» (например, поставим значение «Месяц»), то SQL-запрос платформы изменится аналогично рассмотренному примеру для регистра накопления с видом остатки. Будут добавлены поля выбранных периодов («ПериодДень», «ПериодМесяц» и т.д.) в секции запроса «SELECT» и «GROUP BY». Для нашего примера это месяц. Поля и группировки будут добавлены для всех вложенных запросов и, конечно, содержаться в результатирующей выборке. В нашем примере, выражения в поле запроса для получения периода будет таким:
Принцип получения значений периода был описан выше для регистра с видом «Обороты».
Заключение
Если представить действия SQL-запросов схематично, то выглядеть это будет примерно так:
По схеме видно, что наиболее оптимальным образом платформа работает с виртуальной таблицей «Обороты» для регистра накопления с видом «Обороты», поскольку использует рассчитанных итоги по оборотам в разрезе месяцев. И лишь в тех случаях, когда рассчитанных итогов для периода нет, тогда использует таблицу движений. Для регистра вида «Остатки» всегда используется таблица движений вне зависимости от настроек хранения итоговых записей. Именно поэтому следует внимательно отнестись к настройке вида регистра накопления при проектировании структуры метаданных конфигурации.
Интересен тот факт, что если для регистра накопления отключить использование итогов, то тогда запрос к виртуальной таблице «Остатки» станет невозможным. Будет появляться такая ошибка:
Причем, данная ошибка будет не смотря на то, что виртуальная таблица «Обороты» для регистра накопления с видом «Остатки» использует только таблицу движений.
Что дальше
В следующих статьях будет рассмотрена работа платформы с виртуальными таблицами «Остатки» и «Остатки и обороты». Также коснемся работы агрегатов регистра накопления.
Регистры накопления. Агрегаты в оборотных регистрах
О регистрах накопления
В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.
Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.
Больше года назад сайт был закрыт. Некоторые из его материалов будут реанимированы на Инфостарт.
Конкретно в этой статье речь идет о механизме агрегатов оборотного регистра накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.
Предисловие
В предыдущих статьях мы говорили о структуре хранения регистров накопления в базе данных, работе платформы с виртуальной таблицей «Обороты», также «Остатки» и «Остатки и обороты» этих регистров в зависимости от настроек хранения итогов. Все эксперименты проводились на тестовой конфигурации, содержащей два регистра накопления видов «Остатки» и «Обороты» (подробнее см. в предыдущих статьях).
Сегодня в статье рассмотрим действия платформы при работе с агрегатами оборотных регистров накопления.
Что это за «зверь»?
В предыдущих статьях были рассмотрены вопросы хранения регистров накопления в SQL-базе данных, а также принцип работы платформы с виртуальными таблицами регистров и формируемые при этом платформой SQL-запросы:
Сегодня мы коснемся возможности задействовать механизм произвольных агрегатов для регистров накопления с видом «Обороты». С их помощью можно значительно ускорить формирование отчетов по регистрам накопления в тех случаях, когда количество записей в регистре составляет сотни тысяч, миллионы и более.
Агрегаты позволяют создать заранее рассчитанные данные для формирования отчетов на подобие итогов регистров накопления. Последние рассчитываются платформой автоматически (при условии включения использования итогов для регистра) в отличии от агрегатов. Но для чего нужны агрегаты, если подобную задачу выполняют итоги?
Во-первых, итоги рассчитываются в разрезе месяцев и изменить это нельзя, в то время как агрегаты могут рассчитываться в разрезе дня, месяца, квартала, полугодия и года. Во-вторых, разрезы агрегатов могут быть произвольными (любой состав измерений регистра накопления), в отличии от итогов, которые рассчитываются по полному составу регистра.
Общую информацию об агрегатах оборотных регистров накопления Вы можете посмотреть на официальном сайте. Далее в статье мы рассмотрим создание и настройку агрегатов, а также принцип работы платформы с ними на стороне базы данных. Для примеров будет использоваться тестовая конфигурация, используемая в перечисленных выше статьях.
Создание и настройка
Пользователю понадобился отчет, показывающий обороты номенклатуры в разрезе складов по годам. Вот пример сформированного отчета:
Ничего сложного в запросе, получающем данные для отчета, нет. Используя виртуальную таблицу оборотов мы получаем общее количество оборота по годам. Вот текст запроса отчета:
В одной из предыдущих статей мы уже рассматривали какой SQL-запрос формирует платформа при использовании виртуальной таблицы оборотов. В нашем примере он будет следующий:
Далее рассмотрим влияние использования агрегатов на изменения формируемого SQL-запроса платформой, при этом текст запроса на языке платформы в отчете останется прежним, но перед этим создадим и настроим агрегат.
В режиме конфигуратора перейдем в свойства регистра накопления «ДвиженияНоменклатуры» на закладку «Данные». Нажмем на кнопку «Агрегаты» для открытия конструктора агрегатов.
В конструкторе добавим новый агрегат для всех измерений регистра с периодичностью «Год» (вспомните, отчет будет формировать обороты в разрезе этой периодичности). Параметр «Использование» оставим без изменений. Обновим конфигурацию базы данных.
Этими действиями мы создали агрегат, который будет хранить итоговые записи с периодичностью «Год»(а не «Месяц», как это делает стандартный механизм итогов). Теперь нам нужно включить использование агрегатов в режиме 1С:Предприятие. Откроем стандартную утилиту управления итогами, вкладка «Агрегаты». Здесь нам нужно проделать следующие действия:
1. Включить режим агрегатов. При этом стандартный механизм итогов будет отключен.
3. Перестроим агрегаты. Этим действием мы заполним таблицы агрегатов соответствующими настройкам агрегата записями по таблице движений регистра.
При перестроении агрегатов предлагается указать два параметра: максимальный относительный размер и минимальный эффект от перестроения (см. скриншот слева).
Агрегат создан, настроен и готов к использованию. Далее рассмотрим изменение SQL-запроса платформы при включенном агрегате.
Сторона СУБД
Выполним запрос отчета повторно. На этот раз платформа сформирует следующий SQL-запрос:
Если кратко, то запрос получает данные по оборотам из таблицы агрегата (ее мы заполнили при перестроении агрегата) и таблицы новых оборотов агрегата (в нее попадают новые обороты по регистру до перестроения или обновления агрегата).
Для лучшего понимания работы агрегатов разберем структуру таблиц базы данных, которые используются для их функционирования.
Если для оборотного регистра накопления создан хотя бы один агрегат, то обязательно будут созданы следующие таблицы:
1. Таблица настройки агрегатов регистра накопления.
Здесь сохраняются настройки агрегатов регистров накопления, которые мы установили в режиме 1С:Предприятия (режим агрегатов, использование агрегатов).
2. Таблица списка агрегатов регистра накопления.
Таблица содержит список агрегатов и их параметры (состав измерений, периодичность, использование и др.).
3. Таблица новых оборотов
Агрегаты не могут обновляться автоматически при выполнении движений по регистру, как это происходит в режиме итогов. Поэтому при выполнении движений/проведении документа новые обороты по регистру записываются в таблицу новых оборотов, а после при выполнении обновления/перестроения агрегатов переносятся в основную таблицу агрегатов. Состав таблицы зависит от структуры регистра и агрегатов.
4. Таблица буфера оборотов
Таблица буфера оборотов используется при обновлении агрегатов и имеет структуру, аналогичную таблице новых оборотов (см. выше). Если перестроение агрегатов формирует данные таблицы агрегатов заново, то обновление лишь переносит записи из таблицы новых оборотов в таблицу агрегатов.
Чтобы в момент обновления агрегатов обеспечить стабильную, параллельную работу пользователей и используется таблица буфера оборотов. В момент обновления агрегатов все записи из таблицы новых оборотов переносятся в таблицу буфера, после чего именно он используется для обновления агрегата. 
Если в этот момент пользователи записывают новые движения в регистр накопления, то они будут добавляться в таблицу новых оборотов и никак не повлияют на таблицу агрегатов. Они будут перенесены только при последующем обновлении агрегата.
5. Таблица статистики запросов
Подробно останавливаться на ней мы не будем. Отмечу лишь, что собранная статистика используется платформой 1С:Предприятия для создания оптимальных агрегатов.
Эта возможность доступна в режиме 1С:Предприятия. Выгрузив оптимальные агрегаты в файл-описание формата XML, Вы сможете загрузить их в конструкторе агрегатов в режиме конфигуратора.
Оптимальные агрегаты нужно рассматривать как рекомендации платформы. Решение об использовании того или иного агрегата должен принимать разработчик.
6. Основная таблица агрегатов
Структура таблицы агрегата зависит от его настроек (периодичность, состав измерений). Например, так выглядит таблица с включенной периодичностью и составом полей из двух измерений (номенклатура и склад) (см. справа).
Если у агрегата отключить периодичность и убрать из состава одно измерение, то таблица агрегатов изменится следующим образом:
Назначение каждого поля таблицы легко понять, посмотрев расшифровку полей ранее рассмотренных таблиц.
Не была упомянута таблица «AccumRgAggDims», хранящая коды измерений агрегатов регистров накопления, т.к. в нашем случае она имеет мало значения. О ней Вы можете найти информацию самостоятельно.
Вернемся к запросу
В самом начале был представлен SQL-запрос платформы 1С:Предприятие 8.2 для получения оборотов по регистру «ДвиженияНоменклатуры» в разрезе лет, номенклатуры и складов. В запросе как-раз использовалась таблица агрегатов (получения уже сформированных агрегатов) и таблица новых оборотов (для получения данных по оборотам, еще не перенесенных в таблицу агрегатов).
За счет того, что запрос получает данные итоговых записей в разрезе лет, а не в разрезе месяцев (как это было бы при использовании стандартного механизма итогов), время выполнения запроса значительно сокращается, т.к. объем обрабатываемых данных значительно меньше.
Сравним SQL-запросы платформы для получения данных оборотов с использованием стандартного механизма итогов и при использования агрегатов.
Эффект
С помощью встроенной обработки создания документов в тестовой конфигурации были созданы 1.234.620 документов «Приходный ордер» и 1.161.714 документов «Расходный ордер». В общей сложности эти документы создали 16.131.357 записей движений в регистре «Движения номенклатуры».
Эти данные не покажут значительной разницы в производительности запросов, но заложенный принцип оптимизации должен быть понятен. В нашем примере среднее время выполнения запроса с использованием итогов составит 39.5 миллисекунд. Запрос же при использовании агрегатов выполнится в среднем за 22.9 миллисекунд. Абсолютные значения времени небольшие, но относительная разница существенная. SQL-запрос при использовании агрегатов выполнился быстрее на 42%. Согласитесь, разница существенная.
Основная причина ускорения времени выполнения запросов заключается в снижении обрабатываемого объема данных. Например за 23 года по 3 складам и 15 позиций номенклатуры стандартный механизм итогов создаст следующее количество записей в таблице итогов:
В случае же использования агрегата с периодичностью «Год» итоговые записей будет в 12 раз меньше:
Конечно, смысл использовать агрегаты появляется только в том случае, когда время выполнения запроса для получения данных оборотного регистра накопления будет заметно пользователям, а не только инструментам замера производительности.
Пример фактических планов выполнения запросов по итогам и агрегатам Вы можете посмотреть на следующем скриншоте.
Вместо заключения
Платформа 1С:Предприятие 8.2 позволяет значительно ускорить обращение к оборотным регистрам накопления за счет использования «собственных итогов», или агрегатов. Выше был продемонстрирован пример оптимизации за счет агрегатов и рассмотрен принцип их работы.
В примере показано ускорение выполнения итоговых оборотов по годам в разрезе номенклатуры и складов. Для этого был создан агрегат с периодичностью «Год» и составом измерений «Номенклатура» и «Склад». Этот агрегат является оптимальным для решения поставленной в начале статьи задачи.
Но если бы мы создали агрегат, например исключив из состава измерение «Номенклатура», то платформа бы не смогла его использовать при формировании отчета, так как он не содержит итогов в разрезе номенклатуры. В этом случае отчет формировался значительно медленнее (даже медленнее чем при включенном режиме итогов), т. к. использовалась бы только таблица движений. Именно поэтому так важно создать оптимальные агрегаты с правильной периодичностью и составом измерений. Последнее зависит от конкретной задачи.
Выполнять эту операцию рекомендуется в моменты наименьшей нагрузки на сервер 1С:Предприятия.
Что дальше
На этом коротая серия статей о внутреннем устройстве регистров накопления закончена. Конечно, не все вопросы и нюансы были раскрыты. Вернемся к вопросам индексов и внутреннем устройстве других объектов платформы в последующих статьях.