Регистры накопления. Структура хранения в базе данных

О регистрах накопления

В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.

Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.

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

Назначение объекта

 Платформа 1С:Предприятие 8 предоставляет разработчиком конфигураций использовать такой объект как "Регистр накопления". Регистры накопления предназначены для хранения числовых показателей в нескольких разрезах во времени. Общую информацию о возможностях и назначении этих регистров Вы можете узнать на официальном сайте. Если рассматривать его использование в рамках типовых конфигураций от фирмы "1С", то самым наглядным примером будет регистр накопления "Свободные остатки", которых хранит данные об остатках номенклатуры в разрезе складов, качества, характеристик и серий.

Здесь мы видим, что в таблице регистра хранится количество номенклатуры для каждого отдельного склада, плюс показатели для каждой позиции номенклатуры "разрезаны" по ее качеству, характеристикам и сериям. В итоге, именно регистр накопления позволяет получать доступ к этим данным более оптимальным образом, поскольку структура хранения этого регистра построена таким образом, чтобы конечные SQL-запросы, формируемые платформой, получали необходимый результат за наименьшее время и с приемлемой нагрузкой на СУБД.

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

Все эксперименты будем проводить на тестовой конфигурации с двумя регистрами накопления и двумя документами. Структура метаданных конфигурации Вы можете видеть на следующем скриншоте.

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

И так, приступим!

Таблицы и их назначение

Каждый регистр накопления состоит из нескольких таблиц базы данных.

Таблица движений

Начнем с того, что бывает два вида регистров накопления: остатки и обороты. Выше было сказано, что в тестовой конфигурации мы создали как раз по регистру каждого вида.

Главное отличие этих видов: для регистра накопления с видом "Остатки" ведется учет остатков в разрезе измерений, а также появляется возможность использовать виртуальную таблицу "Остатки". Но как это влияет на структуру хранения регистра в базе?

Для начала отметим тот факт, что вне зависимости от вида регистра в базе данных всегда присутствует таблица движений с именем "AccumRg[n]", где n  — некоторый номер, который присваивается платформой автоматически. В нашей тестовой базе были созданы две таблицы движений регистров накопления:

Структуры таблиц практически идентичные, за исключением одного поля -"_RecordKind" ("ВидДвижения"), которое присутствует только в регистре с видом "Остатки". Для регистра с видом "Обороты" нет смысла указывать вид движения, поскольку приход делается положительным показателем, расход — отрицательным. Различие между таблицами двух регистров накопления могут зависеть от состава измерений, ресурсов и реквизитов в регистре, но в нашем случае состав одинаковый.

Таблицы остатков и оборотов

Теперь поговорим о таблицах, характерных для каждого вида регистра накопления. Если вид регистра накопления установлен как "Остатки", то для него кроме таблицы движений создается таблица остатков с именем "AccumRgT[n]", если же вид регистра "Обороты", то тогда создается таблица "AccumRgTn[n]". Структуры таблиц идентичные, за исключением записываемых в них данных.

Состав полей ("_Fld") зависит от структуры регистра (измерений, ресурсов, реквизитов). Единственный вопрос, который может возникнуть при рассмотрении этих таблиц — это назначение поля "_Splitter". Тут все достаточно просто. Регистры накопления имеют такой параметр как "Режим разделения итогов".

Его использование позволяет увеличить параллельность работы пользователей при записи движений в регистр накопления. В дальнейшем в режиме 1С:Предприятие можно включить или отключить разделение итогов для регистра. Например, если записываются движения двумя документами, при этом значения в измерениях одинаковые (например, по одной номенклатуре и складу). Тогда эти движения должны повлиять на итоги одних и тех же пар значений "Склад-Номенклатура". Чтобы не возникло ожидание на блокировке, оба документа помещают записи об изменении итогов в таблицу, но с разным значением поля "_Splitter".

Касательно данных, записываемых в каждую из таблиц. В таблице остатков ("AccumRgT[n]") хранятся лишь записи об остатках. Приведем пошаговый пример изменения записей в этой таблице при проведении документов.

1. Движения по регистру "ОстаткиНоменклатуры" отсутствуют.

Все просто: нет движений по регистру "ОстаткиНоменклатуры" — нет записей в таблице остатков этого регистра.

2. Оприходованы товары "Товар 1" и "Товар 2" на склад "Склад 1" на дату 1.01.2013. 

Вот и первый документ проведен. Мы оприходовали два товара 1 января 2013 года. Поскольку текущая дата 15.06.2013, то платформа создает записи об итоговых остатках для каждого товара и склада на каждый месяц, начиная с месяца оприходования товаров. Так, например, первые две записи с периодом "4013-02-01 00:00:00:000" показывают остатки на конец января 2013 года. Аналогично записываются остатки последующих месяцев до установленной границы рассчитанных итогов регистра (об этом речь пойдет ниже, сейчас граница установлена на 31 мая 2013 года, поэтому последняя итоговая запись по остаткам записана на период "4013-06-01 00:00:00:000". Все даты хранятся со смещением в 2000 лет, которое настраивается средствами платформы 1С. Смещение необходимо для обхода ограничения минимального значения даты в SQL Server.

Также обратите внимание на записи с периодом, где период установлен "5999-11-01 00:00:00:000". Это записи остатков номенклатуры на текущую дату. Хранение этих данных позволяет получать данные по актуальным остаткам с минимальными затратами ресурсов, т.к. не нужно обращаться к записям предыдущих периодов. Использование текущих итогов регистра определяется его настройками как и дата рассчитанных итогов. О настройках регистра мы поговорим ниже.

3. Списание товаров со склада

13 апреля 2013 был сделан расход по товарам "Товар №1", "Товар №2" и "Товар №3". Поскольку движения были сделаны в апреле, то платформа пересчитывает итоговые остатки за весь апрель и май. На скриншоте выше отмечены периоды, по которым производился пересчет итоговых остатков и не производился. Таким образом платформа сохраняет актуальные итоговые остатки как за каждый месяц, так и текущие актуальные остатки. Обратите внимание на записи, где итоговые остатки отмечены зеленым цветом. Эти записи говорят нам, что итоговый остаток равен 0. На самом деле не имеет смысла хранить остаток со значением 0, лучше если записи вообще бы не было (чтобы не создавать лишние записи в таблице). К тому же получение остатков с помощью виртуальной таблицы "Остатки" никогда не возвращает записи, если их остаток равен 0.

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

4. Последний приход товаров

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

И так, последнее проведение по регистру — приход товаров от 11 июня 2013. Так как движения по регистру сделаны в июне месяца, а граница рассчитанных итогов — это конец мая, то этот приход повлиял лишь на значения текущих остатков.

Таким образом, в таблице остатков "AccumRgT[n]" сохраняются и поддерживаются  в актуальном состоянии записи итоговых остатков по месяцам, а также текущий остатков.

Таблица оборотов действует по аналогичному принципу, за исключением того факта, что в итогах за месяц хранятся не данные по остаткам, а общий оборот за месяц. Продемонстрируем:

В третьем пункте были записаны движения по приходу товаров в тот же период, что и в пункте 1. Платформа автоматически обновила итоговый оборот за январь 2012 года.

Таким образом, в таблице оборотов "AccumRgTn[n]" сохранятся итоговые данные оборотов по месяцам. При этом, если в итоговые остатки делались на дату начала следующего месяца (например, для итоговых остатков за май месяц делается запись на дату 01.06.2013 00:00:00:000), то итоги по обороту платформа записывает на дату начала текущего месяца (например, итоговый оборот за май месяц будет на дату 01.05.2013 00:00:00:000).

Таблицы настроек хранения итогов

Ранее упоминалось, что для регистров накопления есть настройки, которые можно изменять в режиме 1С:Предприятие. Мы говорили об опции "Использовать текущие итоги", а также "Период рассчитанных итогов". Рассмотрим как хранятся эти настройки и дадим их краткое описание.
Начнем с места сохранения этих настроек. Для каждого регистра накопления создается таблица  "AccumRgOpt[n]", имеющая следующую структуру:

Теперь краткое описание некоторых из них:

1. Уникальный идентификатор регистра накопления — по этому значению платформа определяет к какому именно регистру относятся эти настройки.
2. Использовать текущие итоги — если флаг включен, то для регистров накопления с видом "Остатки" в таблице хранятся итоги на текущую дату. Выше это уже было продемонстрировано. Записи текущий итогов хранятся на дату "5999-11-01 00:00:00:000".
3. Использовать итоги — если параметр включен, то платформа будет делать итоговые записи по остаткам или оборотам (в зависимости от вида регистра накопления).
4. Период рассчитанных итогов — дата, начиная с которой требуется рассчитывать итоги.
5. Использовать разделение итогов — параметр включает / отключает разделение итоговых записей для улучшения параллельности работы пользователей (ранее упоминалось о назначении поля "Splitter").

Ранее находил информацию о том, что таблица настроек хранения итогов "AccumRgOpt[n]" создается один раз для всех регистров накопления в конфигурации. Эксперимент показал, что в последних версиях платформы для каждого регистра накопления создается собственная таблица настроек хранения итогов.

Еще не все

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

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

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

Что дальше

В следующих статьях мы поговорим о работе виртуальных таблиц регистров накопления — "Обороты", "Остатки" и "Остатки и обороты",  также рассмотрим работу произвольных агрегатов.

На мой взгляд, самыми интересными регистрами в платформе 1С являются регистры бухгалтерии и регистры расчета. Первый имеет самую сложную структуру по сравнению с остальными, а у регистров расчета просто интересен сам механизм работы и способы его оптимизации. Поэтому планирую закончить серию про регистры накопления и перейти к более интересным объектам.

Про регистры сведений также можно сделать материал, но на Инфостарт уже есть отличная статья "Регистры сведений 1С. Как это устроено" от Сергея Носкова. Новыми статьями лишь можно взглянуть на этот объект немного с другой стороны.

Но, мы можем копнуть и глубже! Если у сообщества есть интерес к внутренностями работы платформы 1С, то можно рассмотреть и другие темы:

• Внутреннее устройство регистров бухгалтерии и регистров расчета.
• Как платформа хранит клиентский кэш 1С, что там внутри и почему он может сломаться при динамическом обновлении.
• Некоторые трюки с СКД.
• Типовые индексы платформы, в том числе и в регистрах накопления, ведь эту темы мы не касались.
• Почему отказываться от режима совместимости очень важно.
• И многое, многое другое.

Пишите в комментариях какая тема Вам больше всего интересна! И мы что-нибудь придумаем 🙂

Другие ссылки

• Регистры сведений 1С. Как это устроено
• Заметки по SQL: Срез последних — аналог запроса
• Индексы таблиц базы данных