Регистры в системе 1С:Предприятие 7.7.: как есть, как должно быть?

Шемякин Павел, май 2002
Оригинал статьи на http://1csql.virtualave.net

В данной статье будет описана реализация обЪекта "Регистр" в системе 1С:Предприятие 7.7. Подробно будут рассмотрены все возможности, влияющие на структуру и производительность работы с обЪектом "Регистр". Будет проведен анализ текущей реализации и представлен мой взгляд на то какой она должна быть.

Итак обЪект "Регистр", что же он из себя представляет? Если отвлечься от физической реализации, то это таблица состоящая из полей нескольких видов:

1. Измерения - ключевые поля. По умолчанию ключ составляется из всех полей данного типа конкатенацией их в порядке задания в конфигурации.
2. Ресурсы - числовые поля, для каждого из которых определены несколько функций
3. Реквизиты - аналог поля Измерения, с ограничением на функции по Ресурсам.

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

В зависимости от типа регистра: остаточный или оборотный, изменяется набор функций. В первом случае это четыре функции: НачОст, Приход, Расход, КонОст, во втором: только одна - Сумма. Для остаточного регистра функции НачОст, КонОст для полей типа реквизит не определены.

Рассмотрим теперь физическую реализацию обЪекта "Регистр" в системе 1С:Предприятие 7.7. Описание будем проводить для 1С:Предприятие 7.7 SQL версии 18 релиз.

Остаточный регистр

Реализуется с помощью двух таблиц: RGxxx и RAxxx.

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

Замечу, что кроме функции НачОст можно также получить и функцию КонОст, так как остаток на начало текущего периода является остатком на конец предыдущего. Если вам нужно получить остаток на начало какого-то периода, то для поля PERIOD вы должны указать значение начала предыдущего периода (то есть НачОст(01.01.2002) ~ PERIOD = 20020112).

Таблица имеет индекс по умолчанию PERIOD + (конкатенация измерений в порядке следования их в конфигурации). Поэтому вы должны учитывать, последовательность расположения измерений. Первым должно следовать измерение, по которому наиболее часто будет задаваться условие для выборки и так далее. Кроме того имеется возможность создать дополнительные индексы для каждого измерения кроме первого (и это правильно так как индекс для первого измерения уже задан). Для этого в конфигураторе зайдите в свойства измерения на закладку "Дополнительные" и поставьте галку "Отбор итогов". Задать индекс для произвольного набора измерений невозможно.

Вторая таблица содержит все движения записанные документов в модуле проведения. В поле IDDOC содержится идентификатор документа, которому принадлежат эти движения в поле DEBKRED содержится знак движения (0 - приход, 1 - расход). Таким образом данная таблица служит для расчета функций Приход и Расход за выбранный период. Замечу, что поля типа "Реквизит" хранятся только в этой таблице, поэтому для них возможно вычисление только данных функций.

По умолчанию вычисление этих функций производится при помощи соединения с таблицей журналов документов (_1SJOURN) по идентификатору документа (при этом учитываются только проведенные документы, имеющие движения по данному регистру - эти условия указываются по полям CLOSED и RFxxx таблицы журналов). Соединение с таблицей журналов необходимо так как только там содержится дата документа, по которой можно определить входит движение в выбранный период или нет. Согласитесь, что это не есть хорошо. При вычислении оборотов скажем за месяц необходимо просканировать ВСЕ документы в таблице журналов за месяц. Однако данный недостаток можно устранить. Для этого предназначена галка "Быстрая обработка движений" в свойствах регистра. При этом в таблице движений появляется дополнительное поле DATE_TIME_IDDOC и индекс по нему, что позволяет не обращаться к журналу документов. Однако в 18 релизе данная возможность используется системой как-то странно: при получении остатков соединения с таблицей журналов уже нет, но для вычисления оборотов по прежнему идет соединение с таблицей журналов. Причем вычисление оборотов выполняется не просто с помощью отдельного запроса, а при помощи курсора.

По умолчанию в таблице присутствует только индекс по идентификатору документа (включающий также в себя номер строки документа и номер движения). Кроме этого можно добавить дополнительный индекс по измерению или по реквизиту. Для этого нужно в свойствах измерения или реквизита на закладке "Дополнительные" установить галку "Отбор движений". При этом создается индекс по этому реквизиту + либо идентификатор документа, либо поле DATE_TIME_IDDOC (если есть).

Вот так реализованы регистры в системе 1С. Надеюсь вы поняли как на самом деле это должно быть - в конце почти каждого абзаца были указаны недостатки. Суммируем их в рекомендации:

1. Возможность установки периодичности хранения остатков для каждого регистра отдельно.
2. Возможность определения произвольных индексов для таблицы итогов, движений. Возможность отключения индекса по умолчанию
3. Исправление ошибки и оптимизация при вычислении функций Приход и Расход

Хотел бы заметить еще один важный момент в реализации остаточных регистров. Судя по их названию они должны использоваться в основном для получения остатков, но зачастую их используют и для получения оборотов (различные ведомости). Однако вычисление оборотов при помощи регистров совершенно не оптимально. Мало того, что имеется уже описанная выше ошибка, но самое главное - чем больше период для получения оборотов тем дольше будет их вычисление и никакая оптимизация тут уже не поможет. В бухгалтерской подсистеме это сделано лучше - вместе с остатком там хранятся обороты по периодам. Конечно можно использовать для вычисления оборотов оборотные регистры, но зачем для этого заводить еще одну таблицу, когда можно сделать все в одной? Поэтому я считаю, что нужная еще одна рекомендация:

Возможность указания (может быть даже для каждого ресурса в отдельности) хранить итоговые обороты.

Оборотный регистр

В целом реализация оборотного регистра аналогична остаточному регистру. Оборотный регистр также состоит из таких же двух таблиц. Таблица движений полностью аналогична таблице движений остаточного регистра. Таблица итогов содержит не значение функции НачОст, а значение функции Сумма. Состав индексов у таблиц и их смысл такой же как у остаточного регистра. Для оборотного регистра уже учтено замечание 1 - периодичность можно устанавливать для каждого регистра отдельно. Периодичность оборотного регистра отличается от регистра остатков: день, неделя, декада, месяц, квартал, год. Итоги в таблице итогов по периодам хранятся нормально, то есть чтобы получить значение функции Сумма за целый период, поле период нужно приравнять началу выбранного периода (желательно указать условие на нахождение м/у началом и концом выбранного периода).

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

1. При выполнении запроса за нецелый период в функции Сумма, нужно учитывать знак движения
2. Необходимо ввести дополнительный признак - разделять или нет значения функций Приход и Расход для каждого ресурса (или регистра в целом). При этом если данный признак стоит, то использование ДвижениеПриходВыполнить/ ДвижениеРасходВыполнить и функций Приход/Расход не должно вызывать ошибку и наоборот.

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

Шемякин Павел, май 2002.