Признаюсь, что освоение этого объекта конфигурации далось мне не просто. Описание планов видов характеристик читал в различных учебниках и в процессе чтения складывалось ощущение, что суть ясна. К слову сказать, самым доходчивым
я считаю объяснение Евгения Гилева - просто, "на пальцах", с примерами. Но, по прошествии времени, когда встречаю этот громоздкий и до сих пор непривычный термин"План видов характеристик" (далее ПВХ), возникает ощущение, что все таки я не до конца понимаю этот объект.
Вряд ли я начал бы писать эту статью, но в разговорах с коллегами - и программистами и консультантами 1C, профессионализм и умственные способности которых сомнений не вызывают, я встретился с похожим "смешанным чувством" при упоминании о ПВХ.
А раз так, то давайте разберемся, в чем тут причина - либо в чрезвычайной сложности объекта, для осмысления которого необходимо некое озарение, либо дело в неудачной терминологии, выбранной авторами платформы? Ведь до сих пор, встречаясь с различными техническими терминами, мы привыкли к тому, что термин ясно отражает суть стоящего за ним явления.
Итак, в чем здесь дело? - давайте попробуем разобраться.
Отвлечемся от "1С" и попробуем охарактеризовать, например, самолет. Для описания различных параметров самолета нам потребуются набор характеристик, которые мы разобьем на несколько смысловых групп - видов характеристик:
- Технические:
- взлетный вес;
- размах крыльев;
- скороподъемность;
- максимальная скорость;
- полезная нагрузка;
и т.д.
- Экономические:
- цена;
- стоимость обслуживания;
- срок эксплуатации;
- стоимость утилизации;
и т.д.
- Эргономические:
- удобство расположения приборов;
- наличие системы кондиционирования;
- материал обивки кресел;
и т.д.
И если мы скажем, что для описания самолета мы имеем виды характеристик: технические, экономические, эргономические, где каждый вид включает некоторое количество характеристик - всем будет понятно. И для конкретного самолета мы можем говорить
о конкретных значениях характеристик, а на вопрос: "Каковы экономические характеристики некоторой модели самолета?", мы можем ответить:
- цена - 1 000 000 $;
- стоимость обслуживания - 100 000$/мес;
- срок эксплуатации - 10 лет;
- стоимость утилизации - 300 000$.
То есть, мы получили следующую структуру описания параметров самолета:
Виды характеристик:
- Технические;
- Экономические;
- Эргономические;
где каждый из видов характеристик включает ряд соответствующих характеристик.
При описании конкретного самолета, мы можем говорить о значениях характеристик для
данной модели самолета.
Разрабатывая учетную систему для хранения подобных структур, логичным было бы иметь объект метаданных "Виды характеристик", в котором, для нашего случая мы бы создали несколько видов характеристик: "Технические",
"Экономические" и "Эргономические". Далее, в каждом из видов добавили бы характеристики - для вида "Технические": "Взлетный вес", типа "Число", "Полезная нагрузка" типа "Число" и т.д., а заполняя данные о конкретном самолете, мы бы говорили о значениях характеристик, например: характеристика вида "Эргономические", "Материал обивки кресел" имеет значение: "Кожа". И всем все понятно.
Теперь вернемся к 1С и попробуем проделать то же самое. Нам нужно создать 3 плана видов характеристик, в каждом из планов задать соответствующие виды характеристик, после чего для конкретной модели самолета, для вида характеристики задавать характеристику как значение определенного для вида характеристики типа. И, для нашего примера, мы должны будем сказать, что в плане видов характеристик "Эргономические", мы для вида характеристик "Материал обивки кресел" задаем характеристику "Кожа".
То есть, можно использовать такую трансляцию (терминология "1С" - "физический" смсысл термина):
Планы видов характеристик - Виды характеристик;
План видов характеристик - Вид характеристик;
Вид характеристики - Характеристика;
Характеристика - Значение характеристики.
Таким образом, есть проблема в терминологии, которая не совсем соответствует сути описываемых с ее помощью сущностей и на мой взгляд мешает понять основные задачи, которые решаются с помощью ПВХ.
Теперь оставим терминологию в покое и попробуем сформулировать основные функции данного объекта. Итак - в чем основное назначение данного объекта? Оно состоит в возможности создания иерархических структур параметров объектов - характеристик и определять типы их возможных значений. При этом, появляется возможность в качестве типа значения различных реквизитов и ресурсов других объектов выбирать тип Харатеристика.- то есть в системе появляется еще один тип данных "Характеристика", являющийся по сути описанием типов, который мы можем создавать и изменять из пользовательской части.
И если с созданием иерархической структуры параметров, возможностью быть владельцем легко бы справился справочник, то именно формирование нового типа данных "Характеристика" является основным отличием ПВХ.
Ну и еще пару слов о том, "откуда ноги растут" - вообще ПВХ произошел из объекта платформы 7.7, который назывался "Виды субконто" и обслуживал исключительно план счетов, наделяя его возможностью ведения аналитического учета. В платформе 8 данный объект решили сделать более универсальным и появился ПВХ, главной задачей которого по прежнему является обслуживание механизмов бухгалтерского учета, но при этом появилась возможность использовать этот механизм и для других задач. И если в случае с бухгалтерскими объектами многие механизмы "зашиты в платформу", что сильно упрощает жизнь, то при использовании ПВХ для решения других задач, все приходится делать самому (вспомогательные регистры сведений, справочники и пр.), что может вызвать определенные сложности у начинающих и не только, так как получается как правило довольно громоздко - посмотрите как реализован учет по характеристикам в типовой торговле (УТ 10.3).
Надеюсь, эта статья поможет вам чувсвтвовать себя уверенней при работе с этим интересным и безусловно очень полезным
объектом.
ЗЫ:
Для полноты картины, учтя ценные замечания из комментариев к статье, привожу ссылки по теме:
http://v8.1c.ru/overview/CharacteristicReg.htm
http://v8.1c.ru/overview/Term_000000276.htm#1
Так же, за рамками данной статьи остались возможности получения характеристик с помощью СКД (закладка характеристики в конструкторе запросов) и др. Статься не претендует на всеобъемлющую полноту и академическую строгость изложения и является частным мнением автора по изложенному вопросу.
