При разработке в системе 1С:Предприятие, особенно при работе со справочниками вроде «Контрагенты», перед нами часто встает задача хранения дополнительных реквизитов. Эти реквизиты могут быть разнообразными: контактные телефоны, адреса (юридические, фактические, доставки), адреса электронной почты, ссылки на веб-страницы или мессенджеры. При этом каждый контрагент может иметь не один, а несколько таких реквизитов. Возникает закономерный вопрос: какой механизм 1С использовать для их хранения? Будем ли мы использовать табличные части, регистры сведений, подчиненные справочники или, возможно, другие подходы?
Давайте вместе разберем эту важную архитектурную задачу, проанализируем различные варианты, их преимущества и недостатки, а также рассмотрим, как эта проблема решена в типовых конфигурациях 1С.
Для решения задачи хранения множественных контактных данных, таких как телефоны, адреса и e-mail для справочника «Контрагенты», мы можем рассмотреть несколько основных подходов, каждый из которых имеет свои особенности и области применения.
Принцип: Табличные части являются неотъемлемой частью объекта (например, справочника «Контрагенты»). Мы можем добавить в справочник свою табличную часть, например, «КонтактныеДанные», и в ней хранить все необходимые реквизиты: тип контакта (телефон, email, адрес), значение, комментарий и т.д.
Принцип: Регистры сведений — это мощный механизм 1С, предназначенный для хранения произвольных данных в разрезе нескольких измерений. Они могут быть периодическими или непериодическими. Для контактной информации мы можем создать непериодический регистр сведений, где измерениями будут, например, ссылка на контрагента, тип контактной информации и, возможно, номер строки для обеспечения уникальности, а ресурсами — само значение контакта.
Рекомендованный подход: Если вы разрабатываете новую конфигурацию или расширяете существующую, и планируете использовать Библиотеку стандартных подсистем (БСП), то наиболее рекомендованным и универсальным подходом будет использование подсистемы «Контактная информация» из БСП. Эта подсистема разработана для унификации хранения и работы с контактными данными во всей системе.
Подсистема «Контактная информация» из БСП предлагает готовое, унифицированное решение для хранения, обработки и отображения различных видов контактных данных (телефоны, адреса, e-mail, Skype, веб-страницы и т.д.) для любых объектов системы (контрагентов, контактных лиц, организаций, физических лиц). Она избавляет разработчика от необходимости «изобретать велосипед», предоставляя комплексный функционал.
В типовых конфигурациях, использующих БСП (например, УТ11), контактная информация, как правило, хранится в табличной части основного справочника или документа, который является носителем этой информации. Эта табличная часть обычно содержит следующие ключевые поля:
Тип: Перечисление, определяющее общую категорию (например, "Адрес", "Телефон", "Адрес электронной почты", "Skype", "Веб-страница", "Факс", "Другое").Вид: Ссылка на справочник «Виды контактной информации», который уточняет тип (например, для типа "Телефон" видом может быть "Мобильный", "Рабочий", "Домашний").ЗначенияПолей: Это поле хранит XML-представление контактной информации. Такая структура позволяет универсально хранить сложные данные, например, структурированный адрес (страна, регион, город, улица, дом).Значение: Часто это поле хранит более простое представление данных, например, в формате JSON, что удобно для обмена или быстрого доступа к неструктурированным данным.Для поиска по адресным данным (например, по номеру дома или улице) используются специальные функции общего модуля РаботаСАдресами, которые умеют разбирать и анализировать данные из полей ЗначенияПолей.
Настройка видов контактной информации производится в разделе «НСИ и администрирование» -> «Администрирование» -> «Общие настройки» -> «Контактная информация» -> «Виды контактной информации». Здесь вы можете настроить список видов контактной информации, который обычно имеет двухуровневую иерархию:
Общий механизм: Помимо специализированных подходов, 1С предоставляет общий механизм «Дополнительные реквизиты и сведения», который позволяет добавлять произвольные поля в справочники и документы без изменения их структуры через конфигуратор. Это очень удобно для быстрой кастомизации.
Дополнительные реквизиты по своей сути являются частью объекта, хранятся вместе с ним и видны непосредственно на его форме. Их можно использовать для установки различных признаков, которые впоследствии могут быть использованы для отбора в списках, отчетах и при программной обработке. Например, можно добавить реквизит "Тип контрагента" (клиент, поставщик, партнер) если этого нет в базовой структуре.
Дополнительные сведения хранятся в отдельном регистре сведений и не отображаются на основной форме элемента справочника или документа по умолчанию. Доступ к ним осуществляется по команде (например, "Дополнительные сведения") из формы элемента. Этот механизм подходит для хранения информации, которая не является критически важной для отображения на основной форме и может быть представлена как набор отдельных характеристик.
Этот механизм позволяет гибко расширять функциональность объектов без вмешательства в структуру базы данных через конфигуратор, что упрощает обновления и поддержку.
Мы видим, что выбор между табличными частями и регистрами сведений, а также использование готовых подсистем, не всегда очевиден. Давайте проанализируем исторические тенденции и основные критерии выбора.
ЗначенияПолей (XML) и Значение (JSON) для хранения структурированной и неструктурированной информации.Выбор оптимального способа хранения зависит от специфики вашей задачи и требований к системе:
Принимая решение о способе хранения, давайте зададим себе следующие ключевые вопросы, которые помогут нам определить наиболее подходящий вариант:
Если для нас критически важно знать, когда и какие контактные данные были у контрагента в прошлом (например, чтобы восстановить старый адрес доставки), то регистры сведений (особенно периодические) или подсистема «Контактная информация» из БСП с настроенным ведением истории будут наилучшим выбором. Если история не нужна, и нас интересует только актуальное состояние, то табличные части вполне подойдут.
Если мы храним простые текстовые строки (например, один телефон или один e-mail), то любая из опций будет работать. Однако, если речь идет о структурированных адресах с разбивкой по регионам, городам, улицам, домам, да еще и с необходимостью проверки по ФИАС/ГАР, то подсистема «Контактная информация» из БСП предлагает готовое и проверенное решение. Ручная реализация такого функционала на табличных частях или регистрах сведений потребует значительных трудозатрат.
Если контактная информация должна быть унифицирована для различных объектов системы (контрагенты, физические лица, организации, контактные лица) и в будущем планируется интеграция с внешними сервисами (телефония, e-mail рассылки), то БСП является предпочтительным решением. Она обеспечивает единый формат хранения и готовые механизмы для работы с данными.
Для небольшого количества контактов на каждый объект и не очень большого общего объема данных, табличные части просты в реализации и достаточно производительны. Если же предполагается очень большое количество контактов, частые обращения к ним с необходимостью сложного отбора и высокая нагрузка, то хорошо оптимизированный регистр сведений с продуманными индексами может показать лучшую производительность. Однако в большинстве случаев для контактной информации объем данных не настолько критичен, чтобы отказываться от удобства табличных частей в рамках БСП.
Разработка собственного механизма хранения на табличных частях или регистрах сведений может быть быстрее на начальном этапе для простых задач, но может увеличить сложности при дальнейшей поддержке и обновлениях конфигурации. Использование БСП, хоть и требует некоторого времени на изучение, в долгосрочной перспективе существенно упрощает жизнь разработчика, так как вы получаете готовое, поддерживаемое фирмой "1С" решение.
Исходя из нашего анализа, сформулируем практические рекомендации по хранению дополнительных реквизитов контрагентов в 1С:
Используйте подсистему «Контактная информация» из Библиотеки стандартных подсистем (БСП). Это стандартное, наиболее полное и универсальное решение в современных конфигурациях 1С. Она обеспечивает единый подход, богатый функционал (включая проверку адресов по ФИАС/ГАР, ведение истории), легко интегрируется и поддерживается.
Как правило, это реализуется через специализированную табличную часть, например, КонтактнаяИнформация, внутри самого справочника "Контрагенты" (или других объектов, для которых это необходимо).
Пример программного доступа к контактной информации через БСП:
// Получение контактной информации для контрагента
Функция ПолучитьКонтактнуюИнформацию(КонтрагентСсылка)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КонтактнаяИнформация.Вид,
| КонтактнаяИнформация.Представление
|ИЗ
| Справочник.Контрагенты.КонтактнаяИнформация КАК КонтактнаяИнформация
|ГДЕ
| КонтактнаяИнформация.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", КонтрагентСсылка);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
МассивКонтактнойИнформации = Новый Массив;
Пока Выборка.Следующий() Цикл
МассивКонтактнойИнформации.Добавить(Новый Структура("Вид, Представление", Выборка.Вид, Выборка.Представление));
КонецЦикла;
Возврат МассивКонтактнойИнформации;
КонецФункции
// Пример использования
// Контрагент = Справочники.Контрагенты.НайтиПоКоду("000000001");
// Если Контрагент <> Неопределено Тогда
// Контакты = ПолучитьКонтактнуюИнформацию(Контрагент);
// Для Каждого Контакт Из Контакты Цикл
// Сообщить("Вид: " + Контакт.Вид + ", Значение: " + Контакт.Представление);
// КонецЦикла;
// КонецЕсли;
При работе с адресами БСП предоставляет специальные функции для их формирования и разбора, например:
// Предполагается, что АдреснаяСтрока - это строка, введенная пользователем
// и ФункцииРаботаСАдресами.ПолучитьСтруктуруАдреса(АдреснаяСтрока)
// может быть вызвана для валидации и структурирования.
// Пример использования общего модуля РаботаСАдресами для форматирования
// (функции могут отличаться в зависимости от версии БСП)
// ПредставлениеАдреса = ОбщегоНазначенияБСП.СформироватьПредставлениеАдреса(СтруктураАдреса);
Используйте табличные части самого справочника. Этот вариант наиболее прост в реализации и поддержании, когда нет жестких требований к истории изменений, валидации или сложной структуре данных. Это хороший выбор для "чайника", чтобы не усложнять систему на старте.
Пример добавления табличной части в справочник:
// В конфигураторе:
// Открыть Справочник.Контрагенты -> ТабличныеЧасти -> Добавить
// Имя: КонтактныеДанные
// Реквизиты табличной части:
// - ТипКонтактнойИнформации (Тип: ПеречислениеСсылка.ТипыКонтактнойИнформации)
// - Значение (Тип: Строка, НеограниченнойДлины)
// - Комментарий (Тип: Строка)
// В модуле объекта:
// Программный доступ к табличной части
// КонтрагентОбъект = Справочники.Контрагенты.СоздатьЭлемент();
// КонтрагентОбъект.Наименование = "Новый контрагент";
//
// НоваяСтрока = КонтрагентОбъект.КонтактныеДанные.Добавить();
// НоваяСтрока.ТипКонтактнойИнформации = Перечисления.ТипыКонтактнойИнформации.Телефон;
// НоваяСтрока.Значение = "+7 (XXX) XXX-XX-XX";
// НоваяСтрока.Комментарий = "Рабочий телефон";
//
// НоваяСтрока = КонтрагентОбъект.КонтактныеДанные.Добавить();
// НоваяСтрока.ТипКонтактнойИнформации = Перечисления.ТипыКонтактнойИнформации.Email;
// НоваяСтрока.Значение = "info@example.com";
//
// КонтрагентОбъект.Записать();
Применяйте регистры сведений. Это лучший выбор, когда вам необходима история изменений контактной информации, строгий контроль уникальности по нескольким измерениям, или когда данные очень многочисленны и требуют сложного анализа/поиска, который затруднителен при хранении в XML/JSON в табличных частях. Помните о потенциальных проблемах с версионированием основного объекта.
Пример создания регистра сведений для контактной информации:
// В конфигураторе:
// Создать РегистрСведений.КонтактнаяИнформацияКонтрагентов
// Вид регистра: Непериодический (или Периодический, если нужна история)
// Измерения:
// - Контрагент (Тип: СправочникСсылка.Контрагенты)
// - ВидКонтакта (Тип: СправочникСсылка.ВидыКонтактнойИнформации, или ПеречислениеСсылка.ТипыКонтактнойИнформации)
// - Представление (Тип: Строка, для уникальности)
// Ресурсы:
// - Значение (Тип: Строка, НеограниченнойДлины)
// - Комментарий (Тип: Строка)
// Программная запись в регистр:
// НаборЗаписей = РегистрыСведений.КонтактнаяИнформацияКонтрагентов.СоздатьНаборЗаписей();
// НаборЗаписей.Отбор.Контрагент.Установить(КонтрагентСсылка); // Для перезаписи или добавления к существующим
//
// НоваяЗапись = НаборЗаписей.Добавить();
// НоваяЗапись.Контрагент = КонтрагентСсылка;
// НоваяЗапись.ВидКонтакта = Справочники.ВидыКонтактнойИнформации.НайтиПоНаименованию("Телефон рабочий");
// НоваяЗапись.Представление = "+7 (XXX) XXX-XX-XX"; // Уникальный идентификатор записи
// НоваяЗапись.Значение = "+7 (XXX) XXX-XX-XX";
// НоваяЗапись.Комментарий = "Основной телефон";
//
// НаборЗаписей.Записать();
Для добавления единичных, простых дополнительных полей, которые не являются множественными (т.е. одно значение на один контрагент), используйте механизм дополнительных реквизитов и сведений. Это позволяет гибко расширять функционал без модификации конфигурации.
В завершение, подчеркнем, что использование готовых подсистем БСП – это путь к созданию качественных, поддерживаемых и функциональных решений в 1С:Предприятии. Они содержат в себе лучшие практики разработки и учитывают множество нюансов, о которых новичок может даже не догадываться. Если есть возможность, всегда стремитесь к внедрению готовых проверенных решений.