• Начало

• Hare.ru @ дикое место
  • Лирика
  • Политика
  • Хай-тек
  • Синема
  • Лирика 2
• Hare.ru @ коллективный разум
  • Бухгалтерия и прочий учёт
  • Концептуальные работы
  • Полезные технологии
  • Собственные руки TM
• О проекте
• Информация
  • Реклама
  • Телеканал Россия 1 на компьютере

Концептуальные работы

Все статьи раздела

1C:Предприятие. Слово о регистрах.

Дмитрий Малюгин (где-то в 2001)

Ключевой составляющей платформы “1С: Предприятие 7.7” (далее везде просто платформа) является механизм регистров. Безусловно, фирма 1С “угадала”, введя данный объект метаданных. Регистры лежат в основе абсолютного большинства учетных систем, являсь их непременным атрибутом.

На данный момент регистры платформы еще далеко не исчерпали свой ресурс, сложность создаваемых учетных систем на платформе 1С еще не подошла к критической. Тем не менее, уже сейчас временами становится заметной ограниченность в уровне абстрактности понятия регистра. Зачастую это приводит к излишней сложности (“некрасивости”) решений в конечных конфигурациях.

Целью данной данной работы сделана попытка повышения уровня абстракции регистров. Будет предложен простейший регистровый тип (класс), и на его основе создана иерархия регистровых классов.

Простейший тип регистра — хранимый статический массив.

Итак, какие же свойства регистра являются определяющими, что отличает его от обычных таблиц данных? Возможно, кто-то скажет, что главное — это накапливание итогов в ресурсах регистра. Другой укажет на возможность извлечения итогов на любой момент времени, то есть наличие у регистра истории. Третий обратит внимание на невозможность “ручного” изменения состояния регистров и т.д.

На самом же деле все перечисленное второстепенно. Главное в регистрах — это разделение полей регистра на измерения и ресурсы. Измерения — это такие поля регистра, которые необходимо задать, чтобы прочитать/записать значения его полей-ресурсов. Таким образом, простейший тип регистра (начальный класс) требует всего лишь разделения полей на два типа, и всё.

Обращаем внимание на то, чего в данном классе не требуется:

• чтобы ресурсы были обязательно числовыми
• сохранение истории ресурсов

Процедур/функций у данного класса немного:
УстановитьРесурс(Измерение1,...)
ПолучитьРесурс(Измерение1,...).

Реальных примеров, когда использовать статические массивы удобно — множество, а в текущей версии 1С соответствующего объекта, к сожалению, нет. Конечно, можно эмулировать статические массивы с помощью справочников, но это, мягко говоря, не слишком удобно.

Пара слов об измерениях. Измерения не обязательно должны быть строго независимыми друг от друга. В качестве примера можно указать часто встречающиеся в конфигурациях измерения регистров типа “Контрагент”, “Договор”. Ясно, что второе измерение подчинено первому и записывать в младшее измерение договор с контрагенотом А, а в старшее — конрагента Б бессмысленно. Отслеживание правильности заполнения подобных измерений должно быть встроено в платформу.

Динамический массив. Реквизиты движения. Последовательности.

Обобщение понятия статического массива очевидно для всех, кто имел дело с “периодическими” реквизитами справочников. Да, производным классом хранимого статического массива является хранимый динамический массив (ХДМ). Все свойства статического массива плюс необходимость при записи ресурсов указывать время записи, плюс возможность извлечения значений ресурсов на любой заданный момент времени. К процедурам/функциям статики добавляется что-то типа УстановитьВремяЗаписиСчитывания().

В настоящий момент понятие динамических массивов в 1С отсутствует. Более того, в отличие от статических массивов, эмулировать динамические массивы стандартными средствами платформы довольно сложно. Исключение составляет лишь случай одномерного массива. А что делать, если нужен именно многомерный массив? Например, такая задача.

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

В терминах динамических массивов всё просто. Измерения массива — товар, подразделение, ресурсы — цена закупки, цена продажи. Если кто-то ведет прайсы в разрезе поставщиков/покупателей, добавим измерение контрагент. А теперь попробуйте реализовать задачу на текущей версии платформы.

С введением понятия динамических массивов можно будет отказаться от понятия “периодические реквизиты справочника”. Их заменит одномерный динамический массив (кстати, у перечислений тоже можно будет установить как статические, так и периодические реквизиты). То есть периодические реквизиты сотрудника “Подразделение”, “Место работы” и т. д. будут вестись в одномерном динамическом массиве. Измерение “Сотрудник”, ресурсы “Подразделение”, “Место работы” и т. д. Становится понятным, почему при проведении документ может менять как значения периодических реквизитов, так и состояние регистров. На самом деле и то, и другое относится к классу динамических массивов.

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

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

Физически динамические массивы должны храниться в двух таблицах. И в той, и в другой присутствуют поля измерений и ресурсов. В одной хранятся все движения/изменения ресурсов массива, время движения, реквизиты движения (если заданы). В другой таблице находятся актуальные значения ресурсов массива, граница последовательности (ГП) и флаг нарушения ГП (если для массива задан учет ГП).

Встречаются также задачи, в которых не важны конечные состояния массива, а важен лишь учет изменений состояния. В терминах динамических массивов это означает отсутствие у массива измерений, а присутствие лишь ресурсов (точнее изменения ресурсов) и реквизитов движения.

Регистры с суммируемыми ресурсами.

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

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

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

Необходимо также ввести в общий регистр понятие единицы измерения ресурсов, поскольку складывать (вычитать) имеет смысл только однородные ресурсы. Структура единиц измерения должна включать в себя ссылку на справочник(и) единиц (валюты — это тоже единицы измерения ресурсов) и числовой коэффициент пересчета. Смысл коэффициента пересчета должен раскрываться справочником единиц. Такая структура единиц помимо “интеллектуального” расчета итоговых значений ресурсов упростит организацию, например, учета товара в кусках (отрезках).

Регстры остатков.

Наконец, мы подошли к конечному (на текущий момент) уровню иерархии регистров — регистрам остатков (бухгалтерским регистрам). Они отличаются от общих регистров тем, что их движения подразделяются на приход и на расход суммируемых (числовых) ресурсов. Более того, различными могут быть также реквизиты движений на приход и на расход. Таким образом, таблицы учета движений и итогов движений разбиваются на учет движений/итогов на приход и учет движений/итогов на расход. В процедуре ДвижениеВыполнить() необходимо указывать направление движения.

Итоговая иерархическая таблица

Партнеры: