"Расширяемые" регистры и табличные части

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

Целью данной заметки является краткое описание концепции, позволяющей создавать и поддерживать более широкие возможности – расширяемые регистры и табличные части. Реализация данных механизмов представляется оптимальной в виде подсистемы с высокой степенью портируемости и универсальности. Опишем объекты, входящие в подсистему, применив взятую для удобства нотацию имён. Нотация имён имеет рекомендательный характер.

План видов характеристик «Разрезы сочетаний». ПВХ описывает состав и типы данных для изменяемых функционалов, т.е., как и в классическом варианте, описывает «добавляемые» пользователем поля. Если в конфигурации есть несколько задач, решаемых описываемым способом, можно сделать ПВХ иерархическим. Реквизиты – на усмотрение разработчика. В зависимости от решаемых задач варьируются допустимые типы.

Справочник «Сочетания разрезов». Справочник собственно содержит конкретные данные всех изменяемых функционалов, значения «добавленных» пользователем полей. Рекомендуется делать его иерархическим с иерархией групп, что позволит повысить скорость работы с подмножествами его элементов через использование штатной механики платформы, но можно обойтись и без иерархии. Также можно задействовать связь по владельцу. Рекомендуется использовать представление в виде кода и сделать длину наименования нулевой. Если в конфигурации есть несколько задач, решаемых описанным способом, и по каждой прогнозируется рост объёмов данных, имеет смысл создавать отдельные справочники одинаковой структуры – это распараллелит нагрузку. Группа справочника может иметь реквизиты, ускоряющие её обнаружение и, через неё, работу с её элементами. Элемент справочника может не иметь шапочных реквизитов (это – на усмотрение разработчика), но обязательно должен иметь табличную часть «Состав сочетания», содержащую 2 реквизита: «Разрез» (ссылка на ПВХ «Разрезы сочетаний») и «ЗначениеРазреза» (характеристика ПВХ «Разрезы сочетаний»). Каждый элемент справочника содержит уникальное сочетание значений «ЗначенийРазрезов», таким образом, двух элементов с абсолютно идентичными табличными частями быть не должно. Это достигается функционалом общего модуля – поиском имеющихся сочетаний, и лежит на совести разработчика. Именно уникальность элементов принципиально важна.

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

Примерный вид запроса для СКД:

ВЫБРАТЬ Сочетания.Ссылка КАК СочетаниеСсылка ИЗ Справочник.СочетанияРазрезов КАК Сочетания ГДЕ Сочетания.ПометкаУдаления = Ложь И Сочетания.Ссылка В ИЕРАРХИИ (&УслРодительскаяГруппа) // и любое другое условие, позволяющее ограничить объём выборки {ХАРАКТЕРИСТИКИ ТИП(Справочник.СочетанияРазрезов) ВИДЫХАРАКТЕРИСТИК (ВЫБРАТЬ ПВХРазрезыСочетаний.Ссылка КАК ПВХРазрез, ПВХРазрезыСочетаний.Наименование КАК ПВХНаименование, ПВХРазрезыСочетаний.ТипЗначения КАК ПВХТипЗначения ИЗ ПланВидовХарактеристик.РазрезыСочетаний КАК ПВХРазрезыСочетаний ГДЕ ПВХРазрезыСочетаний.ЭтоГруппа = Ложь) ПОЛЕКЛЮЧА ПВХРазрез ПОЛЕИМЕНИ ПВХНаименование ПОЛЕТИПАЗНАЧЕНИЯ ПВХТипЗначения ЗНАЧЕНИЯХАРАКТЕРИСТИК (ВЫБРАТЬ Состав.Ссылка КАК Сочетание, Состав.Разрез КАК Разрез, Состав.ЗначениеРазреза КАК ЗначениеРазреза ИЗ Справочник.СочетанияРазрезов.СоставСочетанияРазрезов КАК Состав И Состав.ПометкаУдаления = Ложь И Состав.Ссылка В ИЕРАРХИИ (&УслРодительскаяГруппа) // и любое другое условие, позволяющее ограничить объём выборки ) ПОЛЕОБЪЕКТА Сочетание ПОЛЕВИДА Разрез ПОЛЕЗНАЧЕНИЯ ЗначениеРазреза} 

За внешний вид запроса благодарю обработку Evg-Lylyk (хотя сделать переносы строк и вариант для не-управляемых форм было б невредно, ага)

Очевидно, что для поиска нужных сочетаний следует наложить условия на поля СКД, соблюдая их нотацию. Напомню, при наличии символов, недопустимых в именах системных полей, платформа выполняет неявное преобразование данных, переданных ей в ПОЛЕИМЕНИ, и следует соблюдать правила написания пути к данным в отборах СКД, т.е. нечто вида "СочетаниеСсылка.["+ПолеКакЕгоОбозвалаСКД+"]".

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

Главное в работе с регистром то, что вместо статично заданных измерений пользователь имеет дело со строками табличных частей элементов справочника, являющегося измерением. Каждый элемент справочника уникален. При появлении нового сочетания значений создаётся новый элемент справочника. Таким образом, справочник содержит все имеющиеся варианты значений в их сочетаниях, и каждый набор сочетаний позволяет найти соответствующий элемент, а зная его, и запись в регистре. Изменения в составе разрезов могут и должны сказываться на составе табличных частей элементов справочника, но суть не изменится – единственным измерением будет сам этот справочник, хотя для пользователя он может быть сделан вообще «скрытым» чисто интерфейсными средствами или через RLS.

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

В общем случае количество строк в табличных частях разных элементов справочника может быть совершенно разным, поэтому вопрос актуализации и синхронизации целиком ложится на разработчика. Так, если ранее практиковались 2 разреза («Группа контрагентов» и «Регион»), а позже пользователь ввёл разрез «Категория товара», то табличные части элементов справочника, созданные ранее, могут остаться неизменными, если реализация рабочих модулей будет это учитывать; в противном случае следует продумать дописывание в табличных частях строки с новым разрезом и пустым значением (по сути, ту же операцию, что делает платформа при добавлении измерения в регистр разработчиком). Аналогично следует не забыть обработку случаев изменения типа значений ПВХ или удаления элемента ПВХ.

На следующем этапе развития подсистемы можно ввести понятие шаблона, образца сочетания разрезов, и обеспечить наполнение табличных частей не любыми разрезами и их значениями, а только входящими в образец. Это позволит ещё оптимизировать работу с содержимым справочника. Можно при описании образца указывать, является ли значение того или иного разреза обязательным или нет, можно создать механику избирательного доступа к тем или иным значениям разрезов и т.д., вплоть до конструирования псевдо-OLAP систем, т.е. принципа управляемой многомерности, чему, возможно, будет посвящена следующая заметка.