В современных конфигурациях 1С (на платформе 8.3 с использованием БСП) работа с контактной информацией (телефоны, адреса, email) реализована через динамические механизмы. Это означает, что поля на форме не являются обычными реквизитами объекта, а строятся на лету на основании данных специальной табличной части. В связи с этим у разработчиков часто возникает вопрос: как правильно проверить, заполнил ли пользователь номер телефона или адрес, если прямого обращения к полю «Телефон» в коде не существует? Рассмотрим детально все способы решения этой задачи: от простых пользовательских настроек до написания кода.
Прежде чем приступать к написанию кода, проанализируем возможности типового решения. В конфигурациях на базе БСП (ERP, УТ 11, КА 2, БП 3.0) предусмотрен штатный механизм контроля заполнения. Разберем по шагам, как его включить:
После этой настройки система автоматически включит стандартную проверку 1С. При попытке записать контрагента с пустым телефоном платформа выдаст предупреждение и не даст завершить операцию. Это наиболее корректный и предпочтительный метод, так как он не требует внесения изменений в код и легко масштабируется пользователем.
Иногда пользователю или администратору нужно быстро увидеть, у каких контрагентов не заполнены данные, не заходя в каждую карточку. Рассмотрим, как это сделать через механизм Изменить форму, упомянутый в обсуждении. Проанализируем ситуацию: данные хранятся в связанной таблице, и мы можем вывести их в список.
Для этого в списке контрагентов нажмем кнопку Еще — Настроить список. Перейдем на вкладку Отбор, найдем поле Ссылка, развернем его и выберем Контактная информация. Здесь мы можем установить условие: например, где Вид равен «Телефон» и Представление не заполнено. Это позволит визуально контролировать полноту базы данных без привлечения программиста.
Если нам требуется сложная логика (например, проверять телефон только для определенных типов контрагентов или при выполнении специфических условий), нам придется написать код. Рассмотрим, как реализовать проверку в процедуре ОбработкаПроверкиЗаполнения в модуле объекта справочника Контрагенты.
Важно понимать, что вся контактная информация хранится в табличной части КонтактнаяИнформация. Основные колонки, которые нам интересны: Вид (ссылка на вид КИ) и Представление (строка, которую видит пользователь).
Разберем пример кода для проверки заполнения телефона:
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
// Определим вид контактной информации, который нам нужен
// Обычно это предопределенный элемент
ВидТелефона = Справочники.ВидыКонтактнойИнформации.КонтрагентТелефон;
// Поищем строку в табличной части
СтрокаТелефон = КонтактнаяИнформация.Найти(ВидТелефона, "Вид");
Если СтрокаТелефон = Неопределено Или ПустаяСтрока(СтрокаТелефон.Представление) Тогда
// Если строка не найдена или представление пустое — выводим сообщение
ТекстСообщения = "Не заполнен номер телефона контрагента!";
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, , , , Отказ);
КонецЕсли;
КонецПроцедуры
Профессиональный подход в разработке на 1С подразумевает использование функций общего назначения. Проанализируем возможности модуля УправлениеКонтактнойИнформацией. Этот модуль содержит готовые инструменты для работы с КИ, что избавляет нас от прямой работы с табличными частями.
Например, для проверки заполнения можно использовать метод КонтактнаяИнформацияЗаполнена. Рассмотрим, как это выглядит в коде:
ВидКИ = Справочники.ВидыКонтактнойИнформации.КонтрагентТелефон;
Если Не УправлениеКонтактнойИнформацией.КонтактнаяИнформацияЗаполнена(ЭтотОбъект, ВидКИ) Тогда
// Обработка ситуации, когда поле не заполнено
ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Пожалуйста, укажите телефон.");
КонецЕсли;
Этот метод хорош тем, что он учитывает внутреннюю структуру хранения (не только колонку Представление, но и XML/JSON данные в колонке Значение), что делает проверку более надежной.
При реализации проверок следует учитывать несколько критически важных моментов:
Справочники.ВидыКонтактнойИнформации.Наименование), а не по наименованию текстом, так как пользователь может переименовать вид в режиме предприятия.Значение. Если вы пишете сложную проверку (например, корректность кода города), лучше анализировать именно эту колонку с помощью встроенных функций парсинга JSON, предоставляемых БСП.ПередЗаписью вместо ОбработкаПроверкиЗаполнения, не забывайте устанавливать Отказ = Истина, чтобы предотвратить сохранение некорректных данных.Таким образом, мы выяснили, что для простой проверки достаточно настроек в пользовательском режиме, а для гибкого контроля лучше использовать программные методы с опорой на функционал БСП.