Как сделать заполнение Email обязательным при создании партнера в УТ 11.1?

При работе в конфигурации «1С:Управление торговлей 11.1» часто возникает задача по повышению качества ведения клиентской базы. Одной из таких задач является контроль заполнения контактных данных, в частности — адреса электронной почты. Пользователи могут создавать партнеров как напрямую в списке, так и через специализированный «Помощник регистрации нового партнера». В этой статье мы подробно разберем, как реализовать проверку заполнения Email обоими способами: через стандартные настройки системы и с помощью программного кода.

Способ 1. Использование стандартных настроек (без программирования)

Прежде чем приступать к написанию кода в модулях, проанализируем возможности типового функционала. В конфигурациях на базе БСП (Библиотеки стандартных подсистем), к которым относится и УТ 11.1, механизм контактной информации является гибко настраиваемым.

Разберем по шагам, как включить проверку обязательности заполнения:

1. Перейдем в раздел Администрирование, далее выберем пункт Общие настройки.
2. Найдем гиперссылку Виды контактной информации.
3. В открывшемся списке найдем группу, относящуюся к справочнику Партнеры.
4. Внутри этой группы найдем элемент с наименованием Email (или «Адрес электронной почты»).
5. Откроем карточку этого вида контактной информации.
6. Установим флаг Проверять заполнение.

После установки этого флага система автоматически начнет контролировать наличие записи в табличной части контактной информации при попытке записи объекта. Это решение является наиболее правильным, так как оно не требует снятия конфигурации с поддержки и работает во всех формах объекта.

Способ 2. Особенности работы «Помощника регистрации нового партнера»

Рассмотрим ситуацию, когда стандартной настройки недостаточно или требуется более сложная логика. Пользователь в Сообщении 0 задается вопросом: где именно происходит создание партнера при использовании мастера? Выясним причину, почему проверка в ПередЗаписью может работать неочевидно.

Помощник регистрации — это не отдельная обработка, а специальная форма справочника Партнеры (обычно она называется ФормаСоздания). Ее особенность заключается в том, что она собирает данные во временные реквизиты формы на нескольких шагах (этапах), и только на финальном этапе программно создает и записывает объект.

Проанализируем механизм: если вы добавили проверку в модуль объекта, она сработает в момент нажатия кнопки «Готово» в мастере. Однако для пользователя это может быть неудобно — он уже прошел все шаги и только в самом конце получил ошибку. Поэтому, если вы хотите сделать интерфейс более дружелюбным, проверку стоит продублировать и в модуле самой формы помощника на этапе перехода между страницами.

Способ 3. Программная проверка в модуле объекта

Если нам необходимо реализовать проверку программно, правильно использовать предопределенную процедуру ОбработкаПроверкиЗаполнения, а не ПередЗаписью. Это позволит системе штатно подсветить незаполненные поля и выдать стандартное сообщение об ошибке.

Посмотрим на пример реализации логики в модуле объекта справочника Партнеры:

Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    
    // Определим вид КИ, который мы ищем (Email партнера)
    ВидЭлектроннаяПочта = Справочники.ВидыКонтактнойИнформации.EmailПартнера;
    
    // Проверим наличие заполненного адреса в табличной части КонтактнаяИнформация
    ПочтаНайдена = Ложь;
    Для Каждого СтрокаКИ Из КонтактнаяИнформация Цикл
        Если СтрокаКИ.Вид = ВидЭлектроннаяПочта Тогда
            Если Не ПустаяСтрока(СтрокаКИ.Представление) Тогда
                ПочтаНайдена = Истина;
                Прервать;
            КонецЕсли;
        КонецЕсли;
    КонецЦикла;
    
    Если Не ПочтаНайдена Тогда
        ТекстСообщения = "Необходимо заполнить адрес электронной почты партнера!";
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, , , , Отказ);
    КонецЕсли;

КонецПроцедуры

В данном коде мы обходим табличную часть КонтактнаяИнформация. Важно проверять именно колонку Представление, так как именно в ней хранится строковое выражение адреса почты. Также обратите внимание на использование ОбщегоНазначенияКлиентСервер.СообщитьПользователю — это стандартный метод для вывода сообщений, привязанных к контексту ошибки.

Важные нюансы при разработке

Проанализируем дополнительные моменты, которые упоминали участники обсуждения:

1. Проверка при копировании: В Сообщении 0 автор пытался использовать ЭтотОбъект.Ссылка. Для новых объектов, включая созданные копированием, ссылка всегда будет пустой до момента физической записи в базу данных. Поэтому для определения «нового» объекта в коде 1С 8.3 следует использовать метод ЭтоНовый().
2. Разделение Партнера и Контрагента: В УТ 11.1 важно помнить, что сущности «Партнер» (управленческий учет) и «Контрагент» (юридическое лицо) разделены. Помощник регистрации может создавать их одновременно. Убедитесь, что вы требуете Email именно у того объекта, который вам критичен для учета. Обычно контактная информация партнера используется для CRM-маркетинга, а контрагента — для отправки официальных документов (счетов, актов).
3. Типы контактной информации: Не путайте перечисление ТипыКонтактнойИнформации (где хранятся базовые типы: Адрес, Телефон, Email) и справочник ВидыКонтактнойИнформации. Настройка «Проверять заполнение» находится именно в справочнике, так как для одного типа (например, Телефон) может быть создано несколько видов (Мобильный, Рабочий и т.д.).

Таким образом, для решения задачи в УТ 11.1 мы рекомендуем сначала воспользоваться Способом 1. Это минимизирует риски при обновлении конфигурации и полностью решает вопрос обязательности поля Email как в обычных формах, так и в мастере регистрации. Если же требуется специфическая логика (например, требовать почту только для определенных категорий клиентов), используйте Способ 3 с внедрением кода в ОбработкаПроверкиЗаполнения.