Регистры накопления. Виртуальные таблицы. Часть №1: Обороты

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

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

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

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

Виртуальные таблицы

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

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

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

1. "Обороты".
2. "Остатки".
3. "Остатки и обороты".

Последние две становятся доступными только если вид регистра установлен как "Остатки". 

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

Далее в статье проанализируем SQL-запросы платформы 1С:Предприятие 8.2 при обращении к виртуальной таблицам. При этом будем выполнять запросы при различных комбинациях параметров.

Сторона СУБД

Отмечу, что для экспериментов использовал простую тестовую конфигурацию, ссылка на которую приведена в конце статьи. В конфигурации созданы два регистра накопления различного вида, а также два документа для выполнения + и — движений по регистрам. Узнать подробнее о составе объектов тестовой конфигурации Вы можете либо скачав файл конфигурации, либо прочитав статью "Регистры накопления. Структура хранения в базе данных". Используемая версия платформы 8.2.17.153.

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

Виртуальная таблица "Обороты"

Виртуальная таблица "Обороты" есть, как у регистра накопления с видом "Обороты", так и с видом "Остатки". Рассмотрим оба варианта. Начнем с последнего.

Вид регистра "Остатки"

Посмотрим состав полей таблицы оборотов на примере регистра "ОстаткиНоменклатуры".

В нем содержатся поля каждого из измерений, а также поля "Приход", "Расход" и "Оборот" для каждого из ресурсов в регистре. В нашем случае у нас два измерения ("Номенклатура" и "Склад"), а также три поля "КоличествоПриход", "КоличествоРасход" и "КоличестоОборот".

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

В зависимости от установленного параметра "Периодичность" в состав доступных полей вирт. таблицы будут добавляться соответствующие периоды ("ПериодДень", "ПериодМесяц" и т.д.).

Теперь напишем простой запрос для получения оборотов по номенклатуре за период. В параметрах виртуальной таблицы установим поля "НачалоПериода" и "КонецПериода", а в условия добавим отбор по складу "Склад №1". При выполнении запроса платформа сформирует два SQL-запроса к базе данных. Первый запрос получает настройки регистра накопления:

Используя эти настройки, платформа формирует SQL-запрос непосредственно на получение оборотов. Вот так выглядит SQL-запрос платформы для получения оборотов:

"exec sp_executesql N'
|SELECT"+
// Поля виртуальной таблицы ""Обороты""
" T1.Fld22RRef,     // Номенклатура
| T1.Fld23RRef,     // Склад
| T1.Fld24Turnover_,// КоличествоОборот
| T1.Fld24Receipt_, // КоличествоПриход
| T1.Fld24Expense_  // КоличествоРасход"+
// Получаем обороты с помощью вложенного запроса
"FROM ("+
// -- Начало вложенного запроса --
" SELECT
|  T2._Fld23RRef AS Fld23RRef, // Склад
|  T2._Fld22RRef AS Fld22RRef, // Номенклатура"+
// Если вид записи (""RecordKind"") равно 0, тогда это ""Приход"",
// иначе ""Расход"". ""Приход"" берется положительным, ""Расход""
// с отрицательным знаком.
// 1. Поле ""КоличествоОборот"" получает значение оборота с
// соответствующим знаком. Значение поля суммируется
// в разрезе группировок
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|           THEN T2._Fld24
|        ELSE -T2._Fld24 END
|          ) AS NUMERIC(22, 8)) AS Fld24Turnover_,"+
// 2. Поле ""КоличествоПриход"" формируется по тому же принципу,
// за исключением случаев для вида записи ""Расход"". Для него
// берется значение 0.
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|      THEN T2._Fld24
|       ELSE 0.0 END) AS NUMERIC(22, 8)
|            ) AS Fld24Receipt_,"+
// 3. Поле ""КоличествоРасход"". Формируется по тем же принципам,
// что и предыдущие поля, за исключением вида записи ""Приход"".
// Для нее берется значение 0.
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|      THEN 0.0
|       ELSE T2._Fld24 END
|            ) AS NUMERIC(22, 8)) AS Fld24Expense_"+
// Для получения данных по оборотам для регистра вида ""Остатки""
// используется таблица движений регистра ""AccumRg[n]""
"  FROM _AccumRg21 T2 WITH(NOLOCK)"+
// Во вложенном запросе в секции ""WHERE"" указываются отборы
// в соответствии с установленными параметрами виртуальной таблицы.
"  WHERE T2._Period >= @P1     // НачалоПериода
|   AND T2._Period <= @P2      // ОкончаниеПериода
|   AND T2._Active = @P3          // Активность
|     AND ((T2._Fld23RRef = @P4)) // Условие отбора по складу"+
// Группировки результата вложенного запроса по полям:
"  GROUP BY T2._Fld23RRef,     // Склад
|           T2._Fld22RRef      // Номенклатура"+
// Условия отбора во вложенном запросе на сгруппированный результат
// Проверяется, чтобы хотя бы один из выбираемых ресурсов
// (""КоличествоОборот"", ""КоличествоПриход"", ""КоличествоРасход"")
// не равнялся значению 0.
"  HAVING (CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|       THEN T2._Fld24
|        ELSE -T2._Fld24 END
|                 ) AS NUMERIC(22, 8))) <> @P5
|  OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|       THEN T2._Fld24
|       ELSE 0.0 END
|                 ) AS NUMERIC(22, 8))) <> @P5
|  OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|       THEN 0.0
|       ELSE T2._Fld24 END
|                 ) AS NUMERIC(22, 8))) <> @P5"+
// -- Окончание вложенного запроса --
" ) T1', // Присваиваем синоним для таблицы, в
|     // которую поместим результат вложеного запроса"+
// Установим типы и значения параметров, передаваемых в запрос
"N'@P1 datetime,   // Параметр ""НачалоПериода""
|@P2 datetime,     // ""КонецПериода""
|@P3 varbinary(1), // Активность записи, т.е. влияет ли она на итоги
|@P4 varbinary(16),// Парам. ""Склад"", используемый в парам. вирт. таблицы
|@P5 numeric(1,0)',// Значение для проверки ресурсов на знач. 0.
|{ts '4013-01-01 00:00:00'}, // Значение ""НачалоПериода""
|{ts '4014-01-01 00:00:00'}, // ""КонецПериода""
|0x01,                       // Активность записи
|0xBE923860773387FD11E2D2B47CD2CB1E,
|0                           // Проверка на знач. 0 для ресурсов
|" 

Старался подробно разобрать весь запрос. Если будут непонятные моменты, то прошу в комментарии. Исходный текст запроса на языке 1С:Предприятия выглядит следующим образом:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОстаткиНоменклатурыОбороты.Номенклатура,
| ОстаткиНоменклатурыОбороты.Склад,
| ОстаткиНоменклатурыОбороты.КоличествоОборот,
| ОстаткиНоменклатурыОбороты.КоличествоПриход,
| ОстаткиНоменклатурыОбороты.КоличествоРасход
|ИЗ
| РегистрНакопления.ОстаткиНоменклатуры.Обороты(
|                                              &НачалоПериода,
|                                              &КонецПериода,
|                                              , Склад = &Склад)
|                         КАК ОстаткиНоменклатурыОбороты";

В случае, если для виртуальной таблицы также устанавливается параметр "Периодичность", например, в значение "Месяц", то SQL-запрос немного видоизменится:

 "exec sp_executesql N'
|SELECT"+
// Новое поле "Period" ("Период")
" T1.Period_,
| T1.Fld22RRef,
| T1.Fld23RRef,
| T1.Fld24Turnover_,
| T1.Fld24Receipt_,
| T1.Fld24Expense_
|FROM (
|     SELECT"+
// Получаем период во вложенном запросе вместе с остальными данными.
// Значение периода вычисляется из таблицы движений "AccumRg[n]"
// преобразуется к началу периода в зависимости от периодичности.
// Например, для периодичности "Месяц" период приводится к началу
// этого месяца. Также учитывается тот факт, что в таблице движений
// год в значении периода больше текущего года на 2000 лет.
"      DATEADD(DAY,1.0 - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,T2._Period)
|      AS NUMERIC(4)) - 1,DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period)
|      AS NUMERIC(4)) - 2000) - 2000,{ts ''4000-01-01 00:00:00''})))
|                                                               AS Period_,
|      T2._Fld22RRef AS Fld22RRef,
|      T2._Fld23RRef AS Fld23RRef,
|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                       THEN T2._Fld24
|                    ELSE -T2._Fld24 END)
|           AS NUMERIC(22, 8)) AS Fld24Turnover_,
|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                       THEN T2._Fld24
|                    ELSE 0.0 END)
|               AS NUMERIC(22, 8)) AS Fld24Receipt_,
|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                       THEN 0.0
|                    ELSE T2._Fld24 END)
|               AS NUMERIC(22, 8)) AS Fld24Expense_
|     FROM _AccumRg21 T2 WITH(NOLOCK)
|     WHERE T2._Period >= @P1
|           AND T2._Period <= @P2
|           AND T2._Active = @P3
|           AND ((T2._Fld23RRef = @P4))
|     GROUP BY "+
// Для получения оборотов в соответствии с заданной периодичностью
// результат вложенного запроса группируется по полю период и по
// другим измерениям.
"      DATEADD(DAY,1.0 - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,T2._Period)
|         AS NUMERIC(4)) - 1,DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period)
|         AS NUMERIC(4)) - 2000) - 2000,{ts ''4000-01-01 00:00:00''}))),
|      T2._Fld22RRef,
|      T2._Fld23RRef
|     HAVING (
|         CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                           THEN T2._Fld24
|                       ELSE -T2._Fld24 END) AS NUMERIC(22, 8))) <> @P5
|         OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                           THEN T2._Fld24
|                           ELSE 0.0 END) AS NUMERIC(22, 8))) <> @P5
|         OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0
|                           THEN 0.0
|                           ELSE T2._Fld24 END) AS NUMERIC(22, 8))) <> @P5
|    ) T1',
|N'@P1 datetime,
|@P2 datetime,
|@P3 varbinary(1),
|@P4 varbinary(16),
|@P5 numeric(1,0)',
|{ts '4013-01-01 00:00:00'},
|{ts '4014-01-01 00:00:00'},
|0x01,
|0xBE923860773387FD11E2D2B47CD2CB1E, 0"

Если в виртуальной таблице периодичность установлена "Авто", то в SQL-запросе будут содержаться поля периода для каждой из получаемой в запросе периодичности ("День", "Месяц", "Год" и т.д.). Причина, по которой платформа хранит значения периода с увеличением части даты "Год" на 2000 лет мне не известна. Если кто из читателей подскажет, буду благодарен.

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

Вид регистра "Обороты"

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

Как и в предыдущем случае, в зависимости от параметра "Периодичность" в составе доступных полей появятся соответствующие периоды.

И так, выполним несколько запросов к таблице "Обороты" и проанализируем SQL-запросы платформы. Первый запрос на языке запросов платформы:

Запрос = Новый Запрос;
Запрос.Текст = "
|ВЫБРАТЬ
| ДвиженияНоменклатурыОбороты.Номенклатура,
| ДвиженияНоменклатурыОбороты.Склад,
| ДвиженияНоменклатурыОбороты.КоличествоОборот
|ИЗ
| РегистрНакопления.ДвиженияНоменклатуры.Обороты(
|                                        &НачалоПериода,
|      &КонецПериода,
|      ,
|      Склад = &Склад)
|                         КАК ДвиженияНоменклатурыОбороты" 

Запрос принимает также три параметра: "НачалоПериода", "КонецПериода" и "Склад". Как начало периода возьмем начало 2012 года, конец периода — 13 апреля 2013 00:00:00. Склад пусть будет "Склад №1".

Первым делом платформа 1С:Предприятие получит настройки регистра накопления, к которому выполняется запрос. Запрос будет идентичный рассматриваемому ранее примеру, пойдем дальше. Сформированный платформой SQL-запрос тогда будет такой:

"exec sp_executesql N'
|SELECT"+
// Результатирующие поля выборки
" T1.Fld27RRef,      // Номенклатура
| T1.Fld28RRef,      // Склад
| T1.Fld29Turnover_  // КоличествоОборот"+
// Получаем необходимые данные с помощью вложенных запросов
"FROM ("+
//    Выполняем запрос к вложенной таблице, в которой
//    получаем данные по итогам оборотов, а также
//    обороты по тем записям, которые не учтены в итогах
"     SELECT
|      T2.Fld27RRef AS Fld27RRef,    // Номенклатура
|      T2.Fld28RRef AS Fld28RRef,    // Склад
|      CAST(SUM(T2.Fld29Turnover_)   // КоличествоОборот
|           AS NUMERIC(38, 8)) AS Fld29Turnover_
|     FROM ("+
// ++++++++++ ДАННЫЕ ПО ЗАПИСЯМ ИТОГОВ ++++++++++
//         Первым запросом получаем данные по оборотам
//         из таблицы итогов оборотов "AccumRgTn[n]"
//         по месяцам
"    SELECT
|           T3._Fld27RRef AS Fld27RRef, // Склад
|           T3._Fld28RRef AS Fld28RRef, // Номенклатура
|           CAST(SUM(T3._Fld29)         // КоличествоОборот
|          AS NUMERIC(33, 8)) AS Fld29Turnover_
|          FROM _AccumRgTn30 T3 WITH(NOLOCK)"+
//         Накладываем условия на выборку записей
//         В эту секцию входят все параметры виртуальной
//         таблицы "Обороты", которые задает разработчик
//         в тексте запроса платформы. ИСКЛЮЧЕНИЕ:
//         параметр P2 - это не конец периода, а начало
//         месяца параметра "КонецПериода"
"          WHERE T3._Period >= @P1 // Начало периода
|       AND T3._Period < @P2 // Ограничение для итогов
|       AND ((T3._Fld28RRef = @P3)) // Склад"+
//         Группируем результат выбранным в запросе измерениям
"          GROUP BY T3._Fld27RRef, // Склад
|                   T3._Fld28RRef  // Номенклатура"
//         Проверяем, чтобы значения выбранных в запросе ресурсов
//         не равнялось 0
"          HAVING (CAST(SUM(T3._Fld29)
|             AS NUMERIC(33, 8))) <> @P4"+
// --------- ДАННЫЕ ПО ЗАПИСЯМ ИТОГОВ ---------
//
//         Объединяем результаты по записям итогов и движений
"    UNION ALL"+
//
// ++++++++++ ДАННЫЕ ПО ЗАПИСЯМ ДВИЖЕНИЙ ++++++++++
//         Вторым запросом получаем данные по оборотам
//         из таблицы движений  "AccumRg[n]" за период
//         с начала последних рассчитанных итогов и по
//         значение параметра "Конец периода"
"          SELECT
|           T4._Fld27RRef AS Fld27RRef, // Склад
|           T4._Fld28RRef AS Fld28RRef, // Номенклатура
|           CAST(CAST(SUM(T4._Fld29)    // КоличествоОборот
|               AS NUMERIC(27, 8))
|        AS NUMERIC(27, 2))
|                                   AS Fld29Turnover_
|          FROM _AccumRg26 T4 WITH(NOLOCK)"+
//         Условия выборки записей аналогичны запросу
//         к итогам, за исключением:
//         - параметра P2 = начало месяца от значения
//         параметра "Конец периода"
//         - добавилось условие на активность записей
"          WHERE // Ограничение для периода движений
|                 T4._Period >= @P2
|    AND T4._Period <= @P5 // Конец периода
|    AND T4._Active = @P6 // Активность записей
|    AND ((T4._Fld28RRef = @P3))"+ // Склад
//         Группировки и условия выборки аналогичные
//         запросу по итогам
"          GROUP BY T4._Fld27RRef,
|                   T4._Fld28RRef
|          HAVING (CAST(CAST(SUM(T4._Fld29)
|              AS NUMERIC(27, 8))
|           AS NUMERIC(27, 2))) <> @P4"+
//
// ---------- ДАННЫЕ ПО ЗАПИСЯМ ДВИЖЕНИЙ ----------
"   ) T2" +
//    Группируем результат запроса ко вложенной таблице по
//    выбранным измерениям
"     GROUP BY T2.Fld27RRef, // Номенклатура
|              T2.Fld28RRef  // Склад"+
//    Проверяем, чтобы хотя бы одно значение из
//    выбранных в запросе ресурсов
//    было не равно 0. В регистре из примера один ресурс,
//    поэтому условие одно.
"     HAVING (CAST(SUM(T2.Fld29Turnover_)
|          AS NUMERIC(38, 8))) <> @P4
|) T1',
|N'@P1 datetime,  // НачалоПериода
| // Начало месяца от значения
| // параметра ""КонецПериода""
|@P2 datetime,
|@P3 varbinary(16), // Склад
| // Проверка на 0 для полученных записей
|@P4 numeric(1,0),
|@P5 datetime, // Конец периода
|@P6 varbinary(1)', // Активность
|{ts '4012-01-01 00:00:00'}, // Начало периода
| // Начало месяца от значения
| // параметра ""КонецПериода""
|{ts '4013-04-01 00:00:00'},
|0xBE923860773387FD11E2D2B47CD2CB1E, // Склад
|0, // Проверка на 0 для полученных записей
|{ts '4013-04-13 00:00:00'}, // Конец периода
|0x01 // Активность"

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

Если в запросе на языке платформы мы добавим использование параметра "Периодичность" (например, поставим значение "Месяц"), то SQL-запрос платформы изменится аналогично рассмотренному примеру для регистра накопления с видом остатки. Будут добавлены поля выбранных периодов ("ПериодДень", "ПериодМесяц" и т.д.) в секции запроса "SELECT" и "GROUP BY". Для нашего примера это месяц. Поля и группировки будут добавлены для всех вложенных запросов и, конечно, содержаться в результатирующей выборке. В нашем примере, выражения в поле запроса для получения периода будет таким:

"DATEADD(DAY,1.0 - 1,
|        DATEADD(MONTH,
|                CAST(DATEPART(MONTH,T3._Period)
|                             AS NUMERIC(4)) - 1,
|                     DATEADD(YEAR,(CAST(DATEPART(YEAR,T3._Period)
|                             AS NUMERIC(4)) - 2000) - 2000,
|                     {ts ''4000-01-01 00:00:00''}
|                )
|        )
|) AS Period_" 

Принцип получения значений периода был описан выше для регистра с видом "Обороты".

Заключение

Эксперименты с регистром показали, что для виртуальной таблицы "Обороты" платформа 1С:Предприятие 8 имеет разный принцип построения SQL-запросов к базе данных в зависимости от вида регистра накопления ("Остатки" или "Обороты"). Если вид регистра — "Остатки", то SQL-запрос получает данные по оборотам непосредственно из таблицы движений. В случае, если вид регистра "Обороты", то тогда уже используется таблица итогов оборотов и запрос работает более оптимально, нежели чем для регистра остатков.

Если представить действия SQL-запросов схематично, то выглядеть это будет примерно так:

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

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

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

Что дальше

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

Спасибо за внимание! 🙂

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

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

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