Методологические вопросы различий регистра бухгалтерии и регистров накопления

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

Структура

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

Организация регистров

Регистры накопления и бухгалтерии построены, практически, по одной схеме: есть таблица движений и таблица итогов (для регистра бухгалтерии несколько таблиц итогов). Таблица движений является основной, в ней хранятся первичные данные. В принципе, на основе этих данных можно получить любую требуемую информацию. Таблица итогов является вспомогательной и служит для оптимизации получения некоторой информации. Данные, хранящиеся в таблице итогов, являются вторичными по отношению к таблице движений и могут быть восстановлены из данных таблицы движений. Информация в таблице итогов поддерживается в актуальном состоянии, то есть при каждом изменении таблицы движений сразу же обновляется информация в таблице итогов. Для того что бы эта операция производилась эффективно, у таблицы итогов определен индекс, содержащий период и все измерения регистра. Это накладывает ограничение на количество измерений у регистра, так как в MS SQL Server существует ограничение на количество полей входящих в индекс – не больше 16 полей. Таким образом, для регистра накопления можно определить 15 пользовательских измерений. Шестнадцатое поле занято системным измерением период. При этом нужно учитывать, что каждое измерение составного типа занимает 3 поля вместо одного. Это не означает, что нельзя сделать регистр с количеством измерений больше 15, но при разработке такого регистра нужно учитывать этот факт и стараться в последние измерения, не попадающие в индекс, выносить измерения с маленьким количеством возможных значений. К таким значениям могут относиться перечисления, справочники с маленьким количеством элементов, или измерения количество значений, которых ограничено логикой конфигурации.

Дополнительные измерения (субконто)

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

Счет Субконто1 Субконто2 Субконто3
01 Основные средства Склады  
20 Подразделения Статьи затрат  
41 Товары Партии Склады

Данную структуру можно представить в виде следующих регистров накопления:

Разработчик может предусмотреть ведение в одном регистре бухгалтерии по одному счету несколько независимых параллельных учетов. Даная возможность задействуется с помощью признаков учета субконто и признака только обороты. Например, есть регистр бухгалтерии, в котором ведется суммовой и количественный учет, то есть у регистра определены два ресурса - сумма и количество. В плане счетов есть 10 счет, на котором ведется учет материалов. Данный учет ведется в разрезе материалов и складов, на которых эти материалы хранятся. В разрезе складов ведется только количественный учет. Для определения этого свойства у вида субконто Склады на 10 счете сбрасывается признак суммового учета. Тогда можно представить, что по 10 счету ведется два паралелльных учета:

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

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