«Планы видов характеристик» — само словосочетание как таковое уже начинает немного ломать мозг. Да, планы видов характеристик — это довольная сложная вещь в 1С. Они сложны как концептуально, так и технически. Здесь я постараюсь по возможности коротко и по существу изложить концепцию планов видов характеристик, ее техническую реализацию и область применения.

Концепция

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

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

Возможных типов этого реквизита у нас не так уж и много: строка, число, дата, булево и ссылка. Можно сказать и так, что у нас всего два варианта: примитивный тип и ссылочный. При этом ссылочный тип для нас важнее. Он используется чаще. Цвет лучше задавать не строкой: "красный", "зеленый", "синий", а в виде ссылки на элемент справочника. Размер обуви хоть выглядит, как число: 40, 41, 42... но и его тоже лучше задавать как ссылку. Поэтому, во-вторых, нам нужно дать пользователю возможность создавать свои собственные справочники. Пользователь добавляет свой собственный реквизит, например, цвет (или запах, как нам подсказывают из 1С). Скорее всего он захочет, чтобы это была ссылка. И, скорее всего, он захочет ссылку на справочник, которого нет в типовой конфигурации. Надо дать ему возможность создать такой справочник.

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

Реализация

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

Кроме плана видов характеристик вам потребуется создать:

• Справочник, в котором будут хранится все дополнительные ссылки на размер, цвет и т.д. Такой мегасправочник. Там будет все вперемешку, "сапоги с пирогами". Но пользователь этого не увидит, если все настроить правильно, а именно указать план видов характеристик в качестве владельца этого справочника. В поле Дополнительные значения характеристик у плана видов характеристик надо будет затем указать созданный справочник.

• Регистр сведений. В нем будут храниться собственно значения дополнительных реквизитов для того или иного товара. Обычно в этом регистре два измерения: ссылка на объект (в нашем случае товар) и ссылка на план видов характеристик. И один ресурс. Тип ресурса выбираете из раздела Характеристика. Причем, он должен соответствовать указанному ранее измерению

В регистре сведений надо задействовать две фичи. У первого измерения следует задать опцию Ведущее.

У ресурса задать Связи параметров выбора

Это откроет переход к редактированию свойств из формы объекта и сам процесс редактирования будет правильным.

И это одна из самых простых схем! Делают и более сложные. Такие, где набор возможных дополнительных реквизитов зависит от вида товара.

Заключение

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

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

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

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

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

В заключение порекомендую открытый урок, посвященный EDT, который пройдет в OTUS 12 июля. На нем участники обсудят основные возможности EDT и научатся вести разработку через эту среду. Присоединяйтесь, если эта тема для вас актуальна.