При работе с платформой 1С:Предприятие 8.3 программисты часто сталкиваются с необходимостью динамического определения и использования типов объектов. Один из ключевых инструментов для этого — метод Тип(). Однако иногда возникает недопонимание, почему строковое представление типа значения формируется определенным образом, например, ДокументСсылка.Задача, а не слитно, как СправочникСсылкаЗадача. Давайте вместе разберем эту ситуацию, выясним причины такого поведения и рассмотрим лучшие практики.
Метод Тип() в системе 1С:Предприятие является мощным инструментом, который позволяет получить объект типа по его строковому представлению. Это критически важно, когда нам нужно работать с типами, которые могут быть определены динамически, например, на основе данных из справочников или настроек. В большинстве случаев, когда мы передаем в метод Тип() строку, эта строка должна точно соответствовать полному имени типа метаданных, которое зарегистрировано в конфигурации.
Рассмотрим, как это работает на примере. Если у нас есть справочник с именем "Валюты", то полное строковое имя его типа будет СправочникСсылка.Валюты. Аналогично, для документа с именем "РеализацияТоваровУслуг" полное имя типа — ДокументСсылка.РеализацияТоваровУслуг. Метод Тип() ожидает именно такую структуру. Если в метод Тип() передать строку, которая не соответствует полному имени существующего типа метаданных, например, Тип("НеСуществующийТип"), то это приведет к ошибке.
Пример использования метода Тип():
// Корректное получение объекта типа "СправочникСсылка.Валюты"
ОбъектТипВалюты = Тип("СправочникСсылка.Валюты");
// ОбъектТипВалюты теперь содержит ссылку на объект, описывающий тип "СправочникСсылка.Валюты"
// Корректное получение объекта типа "ДокументСсылка.Задача"
ОбъектТипЗадачи = Тип("ДокументСсылка.Задача");
// ОбъектТипЗадачи теперь содержит ссылку на объект, описывающий тип "ДокументСсылка.Задача"
Ключевым моментом, который часто вызывает путаницу, является структура полного строкового имени типа. Для ссылочных объектов метаданных (таких как справочники, документы, перечисления и т.д.) оно всегда состоит из двух основных частей, разделенных точкой:
СправочникСсылка – используется для получения ссылок на элементы справочников.ДокументСсылка – используется для получения ссылок на документы.ПеречислениеСсылка – используется для получения ссылок на значения перечислений.ПланВидовХарактеристикСсылка – используется для получения ссылок на элементы планов видов характеристик.ПланСчетовСсылка – используется для получения ссылок на счета в планах счетов.РегистрСведенийЗапись – используется для работы с записями регистров сведений, когда нам нужно получить тип записи, а не ссылки.Валюты, Задача, РеализацияТоваровУслуг и т.д. Важно, чтобы это имя точно совпадало с именем объекта, как оно указано в дереве метаданных.Таким образом, полное имя типа всегда формируется по строгому шаблону: ВидОбъектаСсылка.ИмяОбъектаМетаданных (или аналогично для других видов объектов, таких как РегистрСведенийЗапись.ИмяРегистра). Точка (.) между префиксом вида объекта и именем объекта метаданных является обязательным разделителем. Без нее платформа не сможет корректно распознать тип, так как будет искать объект метаданных с именем, включающим префикс без разделения.
Например, если мы передадим Тип("СправочникСсылкаВалюты"), система попытается найти в конфигурации объект метаданных вида "Справочник" с именем "СправочникСсылкаВалюты", что, скорее всего, не существует, и приведет к ошибке.
В нашем случае автор столкнулся с конструкцией, которая динамически формирует строку типа, используя СтрокаТипа(строковый) ЭлементОбъектов.Значение(строковый). Предположим, что переменная СтрокаТипа содержит, например, "ДокументСсылка", а ЭлементОбъектов.Значение содержит "Задача". Тогда при простом сложении этих двух строковых значений без учета разделителя получается "ДокументСсылка" + "Задача", что приводит к строке "ДокументСсылкаЗадача". Вот здесь и кроется причина основной путаницы и ошибки!
Для того чтобы получить корректное строковое имя для подстановки внутрь метода Тип(), необходимо использовать конкатенацию с обязательным добавлением точки-разделителя. Мы должны явно указать, что вид объекта и его имя – это отдельные компоненты, разделенные точкой, как того требует синтаксис 1С.
ИмяВидаОбъекта = "ДокументСсылка";
ИмяОбъектаМетаданных = "Задача";
// Правильная конкатенация для формирования полного имени типа
ПолноеИмяТипа = ИмяВидаОбъекта + "." + ИмяОбъектаМетаданных;
// Результат переменной ПолноеИмяТипа будет: "ДокументСсылка.Задача"
// Теперь это строковое значение можно корректно передать в метод Тип()
ОбъектТип = Тип(ПолноеИмяТипа);
Именно такая конструкция, например Тип("СправочникСсылка." + "Валюты"), или в контексте нашей задачи Тип("ДокументСсылка." + "Задача"), позволяет корректно сформировать строковое имя, которое будет правильно интерпретировано платформой. Это демонстрирует, что конкатенация строк — это лишь способ сборки строкового значения, и ее результат должен соответствовать ожидаемому формату полного имени типа.
Еще один аспект, который может вызывать недопонимание у разработчиков, — это то, как типы отображаются в отладчике 1С. Часто, когда мы анализируем значения переменных в отладчике, вместо технического имени типа, такого как ДокументСсылка.Задача, мы видим его синоним, если он задан для объекта метаданных "Задача". Например, вместо ДокументСсылка.Задача может отображаться просто "Задача", или "Задача исполнителя", если такой синоним установлен в конфигураторе для данного документа.
Это сделано для удобства пользователя и программиста, чтобы быстрее и интуитивно понятнее ориентироваться в данных и понимать, с каким типом объекта мы работаем. Однако крайне важно помнить, что внутренне система 1С оперирует именно полными строковыми именами типов, включающими префикс (например, ДокументСсылка) и точку-разделитель. Отображение в отладчике – это лишь "дружественное", человекочитаемое представление, которое не всегда отражает полную техническую структуру имени типа.
Поэтому, когда мы пишем код, особенно динамически формирующий имена типов, нам всегда следует ориентироваться на полное техническое имя, а не на то, как оно отображается в отладчике.
Правильное и осмысленное именование объектов метаданных не только улучшает читаемость и поддерживаемость конфигурации, но и помогает избежать путаницы при работе с их типами, особенно в случае динамического формирования имен. Давайте рассмотрим общие рекомендации, которые помогут вам создавать понятную и логичную структуру метаданных:
СправочникНоменклатура лучше использовать Номенклатура, а вместо СправочникВалюты — Валюты. Это делает имена короче и более лаконичными.Валюты, Контрагенты, Номенклатура, ГруппыИсполнителейЗадач, ПодразделенияОрганизаций.РеализацияТоваровУслуг, ПоступлениеТоваровУслуг, СписаниеДенежныхСредств, Задача (если это документ, который фиксирует задачу как сущность, а не является объектом метаданных "Задача").ЗадачаИсполнителя, ОзнакомлениеСДокументом, СогласованиеЗаявки.В случае автора, объект "Задача" был документом, а не справочником или объектом метаданных "Задача" из подсистемы бизнес-процессов. Поэтому, для него корректным типом является именно ДокументСсылка.Задача, а не СправочникСсылка.Задача или просто Задача.
Основная причина путаницы автора и подобных вопросов заключается в нескольких ключевых моментах, которые мы теперь можем четко сформулировать:
СправочникСсылкаЗадача (как изначально предположил автор), без точки между СправочникСсылка и Задача, является фундаментально некорректной. Платформа 1С требует четкого разделения вида объекта метаданных и его имени именно с помощью точки. Без этого разделителя строка не является валидным полным именем типа.СправочникСсылка было бы ошибочным. Правильный префикс для документа — ДокументСсылка."СправочникСсылка") и имя объекта (например, "Задача"), были просто соединены оператором + без явного добавления точки, результатом будет слипшееся строковое значение "СправочникСсылкаЗадача". Это не соответствует требуемому формату ВидОбъектаСсылка.ИмяОбъектаМетаданных.Помните, что платформа 1С строго следит за форматом полного имени типа. Даже небольшое отклонение, такое как отсутствие точки или использование неверного префикса, приведет к ошибкам при попытке получить тип с помощью метода Тип() или при выполнении других операций, требующих точного указания типа.
Мы настоятельно рекомендуем всегда проверять полные имена типов в конфигураторе или с помощью встроенных функций платформы, чтобы убедиться в их корректности. Например, для любого ссылочного значения (элемента справочника, документа) вы можете получить его тип с помощью функции ТипЗнч(), а затем посмотреть его строковое представление или полное имя типа через свойства полученного объекта типа.
// Предположим, у нас есть ссылка на существующий документ "Задача"
// Замените эту строку на реальное получение ссылки на ваш документ
// Например: СсылкаНаДокументЗадача = Документы.Задача.НайтиПоНомеру("000000001", Дата("20230101"));
// Или: СсылкаНаДокументЗадача = Документы.Задача.ПустаяСсылка(); // Для демонстрации типа
// Чтобы получить реальный объект, если у нас есть только имя типа:
// Если мы знаем, что это документ "Задача", и у нас есть его ссылка
Если НЕ СсылкаНаДокументЗадача.Пустая() Тогда
// Получаем объект типа из существующей ссылки
ОбъектТип = ТипЗнч(СсылкаНаДокументЗадача);
// Получаем полное имя типа в виде строки
СтроковоеИмяТипа = ОбъектТип.ПолноеИмя();
// В данном случае, СтроковоеИмяТипа будет "ДокументСсылка.Задача"
Сообщить("Полное имя типа полученной ссылки: " + СтроковоеИмяТипа);
Иначе
Сообщить("Ссылка на документ не найдена или пустая. Невозможно получить тип.");
КонецЕсли;
Таким образом, понимание структуры полных имен типов, правил конкатенации строк и принципов работы метода Тип() является фундаментальным для эффективной и безошибочной работы с динамическими типами в 1С:Предприятии. Следуя этим рекомендациям, мы сможем избежать распространенных ошибок и писать более надежный и понятный код.