Часто разработчики, особенно пришедшие из других языков программирования, сталкиваются с необходимостью объединить несколько полей в единую логическую сущность. Например, создать тип "ФИО", состоящий из трех строк (фамилия, имя, отчество), или "ЕдиницаХранения" с набором характеристик (цвет, вес, номенклатура, штрихкод). Возникает соблазн использовать для этого механизм платформы "Определяемые типы", но это распространенное заблуждение. Разберемся, почему так делать нельзя и какие инструменты 1С предназначены для решения этой задачи.
Для начала проанализируем, что же такое Определяемый тип в платформе "1С:Предприятие". Это не контейнер для хранения данных и не аналог структуры (struct) или класса. Основная его задача — служить псевдонимом или сборной точкой для уже существующих в конфигурации типов данных.
Рассмотрим ключевые цели, которые решают определяемые типы:
Артикул, указать в нем тип "Строка" с длиной 25, и назначить этот определяемый тип всем нужным реквизитам. Теперь для изменения длины во всей системе достаточно будет поменять ее в одном месте — в настройках типа Артикул.
Справочник.Контрагенты, так и Справочник.ФизическиеЛица. Можно создать определяемый тип ВладелецОбъекта и включить в его состав эти два справочника. Если в будущем появится необходимость добавить в качестве владельца, например, Справочник.Организации, достаточно будет изменить только определяемый тип, и это изменение автоматически применится ко всем реквизитам, которые его используют.
Важнейшее ограничение: определяемый тип не создает новую структуру данных. Он лишь ссылается на существующие. Вы не можете создать определяемый тип "ФИО" и сказать, что он состоит из трех независимых строк. Вы можете лишь указать, что он может принимать значения одного из уже существующих типов. Поэтому попытка использовать его для создания сложного ключа аналитики для регистра обречена на провал.
Задача по созданию "ЕдиницыХранения" с набором различных характеристик (цвет, номенклатура, штрихкод, вес и т.д.) решается в 1С другими, стандартными и эффективными способами.
Это самый распространенный, правильный и идеологически верный способ для платформы 1С. Суть его в том, чтобы создать отдельный справочник, который будет представлять собой уникальный набор характеристик.
Разберем по шагам на примере "ЕдиницыХранения":
КлючиАналитикиНоменклатуры.Номенклатура (тип СправочникСсылка.Номенклатура)Цвет (тип СправочникСсылка.Цвета или Строка)ШтрихКод (тип Строка)Вес (тип Число)ОстаткиТоваров) вместо набора измерений "Номенклатура", "Цвет", "Штрихкод" мы создаем одно измерение: КлючАналитики с типом СправочникСсылка.КлючиАналитикиНоменклатуры.Почему это правильный подход? В типовых конфигурациях, например, в "1С:Управление торговлей", можно найти яркий пример такого подхода — справочник АналитикаУчетаНоменклатуры. Он используется не от хорошей жизни, а для решения фундаментальной задачи производительности. Когда в регистре много измерений, СУБД приходится строить сложные составные индексы. Это может сильно замедлять запись в регистр и выполнение запросов. Объединяя несколько характеристик в ссылку на один справочник, мы сводим множество полей к одному целочисленному идентификатору (ID записи справочника). Индекс по одному полю работает гораздо быстрее, что критически важно для высоконагруженных систем.
Если ваша задача — вести учет вариантов одного и того же товара (например, "Футболка" в разных цветах и размерах), то в большинстве торговых конфигураций уже есть готовый механизм — Характеристики номенклатуры.
Он позволяет для одной позиции номенклатуры создать несколько ее вариантов, отличающихся определенными свойствами. Технически это, как правило, реализовано через подчиненный справочник ХарактеристикиНоменклатуры. В регистрах учета товаров (остатки, продажи) присутствует отдельное измерение Характеристика. Этот подход позволяет не "раздувать" справочник номенклатуры, сохраняя при этом детальный учет в разрезе вариантов.
Этот способ идеально подходит, если набор свойств всегда привязан к номенклатуре и является ее неотъемлемой частью.
Это более гибкий, но и более сложный механизм. Он лежит в основе подсистемы "Дополнительные реквизиты и сведения" и позволяет пользователям в режиме "Предприятие" добавлять новые свойства к объектам, не меняя конфигурацию.
ПВХ — это, по сути, справочник, в котором хранятся сами характеристики (их наименования и типы значений). А значения этих характеристик для конкретных объектов хранятся в отдельном регистре сведений. Этот механизм отлично подходит для добавления описательных, не являющихся ключевыми для учета, свойств. Использовать его в качестве основного измерения в регистрах накопления не рекомендуется из-за сложностей с производительностью запросов, так как для получения значения характеристики потребуется соединение нескольких таблиц.
В обсуждении также упоминался механизм XDTO (XML Data Transfer Objects). Он действительно позволяет описывать и работать со строго типизированными структурами данных. Однако его основное назначение — интеграция и обмен данными с другими системами. Объекты XDTO существуют только в оперативной памяти во время выполнения кода. Их нельзя использовать в качестве типа для реквизита справочника или измерения регистра, то есть их нельзя сохранить в базу данных напрямую как персистентный объект. Поэтому для решения исходной задачи этот механизм неприменим.
Подведем итог. Желание создать сложный тип данных вполне естественно, но для этого нужно использовать правильные инструменты платформы 1С:
Понимание этих принципов поможет создавать не только работающие, но и оптимальные, и масштабируемые решения на платформе "1С:Предприятие".