1с расширение проверка заполнения реквизита

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

Если установить это свойство в значение «Выдавать ошибку», поле Поставщик в форме будет помечено как обязательное для заполнения. А при записи накладной платформа будет контролировать заполненность этого реквизита. Если реквизит окажется не заполнен, платформа выдаст автоматическое сообщение и запись накладной будет отменена.

Разработчик может повлиять на стандартную проверку заполнения, выполняемую платформой. Для этого у него есть два события:

• Одно событие — ОбработкаПроверкиЗаполненияНаСервере — можно обработать в модуле формы.
• Другое событие — ОбработкаПроверкиЗаполнения — можно обработать в модуле прикладного объекта.

У формы, как правило, есть основной реквизит (редактируемый объект) и могут быть реквизиты, не относящиеся к редактируемому объекту, а являющиеся лишь частью формы:

Поэтому серверное событие формы ОбработкаПроверкиЗаполненияНаСервере предназначено для проверки заполнения тех реквизитов формы, которые не относятся к редактируемому объекту. Это данные только формы, у формы могут быть свои причины и алгоритмы для проверки этих данных.

Напротив, событие объекта ОбработкаПроверкиЗаполнения предназначено для для того, чтобы проверить реквизиты основного реквизита формы.

Обработчики обеих событий имеют параметр ПроверяемыеРеквизиты, в который платформа передает массив имен тех реквизитов, которые подлежат проверке. Если после выхода из обработчика в этом массиве все еще останутся какие-то имена реквизитов — платформа выполнит автоматическую проверку оставшися реквизитов.

Поэтому существует несколько сценариев того, как разработчик может встроить свой алгоритм в механизм проверки заполнения:

• самостоятельно проверить заполненность всех реквизитов и очистить массив ПроверяемыеРеквизиты, чтобы платформа не выполняла их проверку
• проверить часть реквизитов самостоятельно, удалить их из массива ПроверяемыеРеквизиты, а оставшиеся оставить на проверку платформе
• добавить в массив ПроверяемыеРеквизиты какие-то реквизиты, чтобы платформа проверила и их тоже
• вообще отказаться от проверки заполненности реквизитов, очистив массив

Все эти сценарии реализуются довольно просто. Например, чтобы самостоятельно проверить заполненность реквизитов, можно выполнить следующий код:

Если Поставщик = Справочники.Поставщики.ПустаяСсылка() Тогда
    Сообщение = Новый СообщениеПользователю();
    Сообщение.Текст = "Необходимо заполнить поставщика!";
    Сообщение.Поле  = "Поставщик";
    Сообщение.УстановитьДанные(ЭтотОбъект);
    Сообщение.Сообщить();
    Отказ = Истина;
КонецЕсли;

// Проверка остальных реквизитов
// ..........

// Очистить массив проверяемых реквизитов, чтобы платформа
// не выполняла их автоматическую проверку
ПроверяемыеРеквизиты.Очистить(); 

Чтобы проверить лишь часть реквизитов, можно выполнить такой код:

Если Поставщик = Справочники.Поставщики.ПустаяСсылка() Тогда
    Сообщение = Новый СообщениеПользователю();
    Сообщение.Текст = "Необходимо заполнить поставщика!";
    Сообщение.Поле  = "Поставщик";
    Сообщение.УстановитьДанные(ЭтотОбъект);
    Сообщение.Сообщить();
    Отказ = Истина;
    // Удалить поставщика из массива проверяемых реквизитов
    ИндексПоляПоставщик = ПроверяемыеРеквизиты.Найти("Поставщик");
    Если ИндексПоляПоставщик <> Неопределено Тогда
        ПроверяемыеРеквизиты.Удалить(ИндексПоляПоставщик);
    КонецЕсли;
КонецЕсли;

Добавить в массив проверяемых реквизитов еще один реквизит можно следующим образом:

ПроверяемыеРеквизиты.Добавить("Комментарий");

А очистить массив проверяемых реквизитов, чтобы ничего не проверять ни самому, ни платформе, можно так:

ПроверяемыеРеквизиты.Очистить();

Вторым параметром в обработчиках этих событий является параметр Отказ. Если ему присвоить значение Истина, то после выхода из обработчика дальнейшая запись объекта будет отменена. Таким образом этот параметр нужно устанавливать в значение Истина тогда, когда ваш алгоритм приходит к выводу, что реквизит не заполнен. В этом случае запись объекта выполнена не будет.

Справка

ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)

УправляемаяФорма.ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)

• Отказ. Тип: Булево. Признак отказа от записи. Если в теле процедуры-обработчика установить данному параметру значение Истина, то запись выполнена не будет. Значение по умолчанию Ложь.
• ПроверяемыеРеквизиты. Тип: Массив. Массив путей к реквизитам, для которых будет выполнена проверка заполнения. Массив может быть модифицирован удалением или добавлением путей к необходимым реквизитам.

Вызывается расширением формы при необходимости проверки заполнения реквизитов при записи в форме, а также при выполнении метода ПроверитьЗаполнение(). Для вызова проверки заполнения системой необходимо, чтобы у формы (с которой происходит работа) было установлено свойство ПроверятьЗаполнениеАвтоматически. В этом случае вначале будет вызван данный обработчик, а затем обработчик ОбработкаПроверкиЗаполнения() модуля объекта.

Позволяет разработчику самостоятельно реализовать проверку заполнения в обработчике события. При этом в обработчике можно полностью отказаться от системной обработки (очистив список проверяемых реквизитов), отказаться от проверки системой части реквизитов (выполнив проверку отдельных реквизитов особенным образом и исключив эти реквизиты из списка), а также добавить для проверки другие реквизиты, проверка которых не была указана.

Для формы документа, если при конфигурировании для документа свойство Проведение установлено в Разрешить, событие вызывается только при проведении. Если документ не проводится (свойство Проведение установлено в Запретить), то вызывается при записи.

ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)

ДокументОбъект.ИмяДокумента.ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)

• Отказ. Тип: Булево. Если в теле процедуры-обработчика установить данному параметру значение Истина, то будет выполнен отказ от продолжения работы после выполнения проверки заполнения. Значение по умолчанию Ложь.
• ПроверяемыеРеквизиты. Тип: Массив. Массив путей к реквизитам, для которых будет выполнена проверка заполнения. Массив может быть модифицирован удалением или добавлением путей к необходимым реквизитам.

Вызывается расширением формы при необходимости проверки заполнения реквизитов при записи или при проведении документа в форме, а также при выполнении метода ПроверитьЗаполнение(). Если для документа при конфигурировании свойство Проведение установлено в Разрешить, то вызывается только при проведении. Если документ не проводится (установлено Запретить), то вызывается при записи.

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

Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)

    // Проверим заполненность реквизита «Покупатель»
    Покупатель = ПроверяемыеРеквизиты.Найти("Покупатель");

    Если Не ЗначениеЗаполнено(Покупатель) Тогда
        
        // Если он не заполнен, сообщим об этом пользователю
        Сообщение = Новый СообщениеПользователю();
        Сообщение.Текст = "Не указан Покупатель, на которого выписывается товарная накладная!";
        Сообщение.Поле = "Покупатель";
        Сообщение.УстановитьДанные(ЭтотОбъект);
        Сообщение.Сообщить();
            
        // Сообщим платформе, что мы сами обработали проверку заполнения реквизита «Покупатель»
        ПроверяемыеРеквизиты.Удалить(Покупатель);

        // Так как информация не консистентна, то продолжать работу дальше смысла нет
        Отказ = Истина;
            
    КонецЕсли;

    // Сообщим платформе, что мы сами обрабатываем проверку реквизита товар в табличной части «Товары»
    ПроверяемыеРеквизиты.Удалить(ПроверяемыеРеквизиты.Найти("Товары.Товар"));

    // Обходим строки и проверяем заполнение реквизита
    Для Индекс = 0 По Товары.Количество()-1 Цикл
        СтрокаТовар = Товары.Получить(Индекс);
        Если Не ЗначениеЗаполнено(СтрокаТовар.Товар) Тогда
            Сообщение = Новый СообщениеПользователю();
            Сообщение.Текст = "В строке " + Индекс + " не заполнено значение товара";
            Сообщение.Поле = "Товары[" + Индекс + "].Товар";
            Сообщение.УстановитьДанные(ЭтотОбъект);
            Сообщение.Сообщить();
            Отказ = Истина;
        КонецЕсли;
    КонецЦикла;
    
КонецПроцедуры

Поиск:
1С:Предприятие • Обработка проверки заполнения • Проверяемые реквизиты • Реквизит • Управляемая форма

Думаю, без преувеличения каждому разработчику на практике приходилось реализовывать задачи по проверке корректности заполнения тех или иных реквизитов в справочниках, документах и т.п. Задача достаточно простая, и путей решения может быть множество. У каждого есть свои плюсы и минусы. Кто-то использует расширения, кто-то включает режим поддержки с возможностью изменения и меняет свойства у реквизитов объектов, контроль над которыми запросил заказчик и т.д. и т.п.

Мне пришла в голову идея (возможно, и скорее всего не первому) глобальнее подойти к решению этого вопроса.

Идея довольно проста. Почему бы не сделать этот функционал более гибким? Без боязни потерять ту или иную проверку после обновления?

Для этого необходимо лишь создать хранилище этих настроек, грамотно подойти к вопросу реализации алгоритмов проверки, и не забыть про права пользователей, позволяющие им использовать функционал.

И так. Что нам потребуется.

— несколько подписок на события;

— непериодический независимый регистр сведений для хранения настроек контроля;

— серверный общий модуль для служебных алгоритмов;

— конфа, написанная на БСП;

— прямые руки.

Рисунок 1. Структура подсистемы.

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

В моем случае логика была следующей: справочники и планы видов характеристик я проверяю перед записью, поскольку записанный элемент справочника или ПВХ уже влияет на учет; документы я проверяю в момент проведения, поскольку, очевидно, непроведенный документ не содержит проводок, а следовательно не влияет на учет. Случаи формирования отчетов по документам не глядя на флаг проведения я не рассматриваю, оставлю это на совести разработчиков, которым приходит в голову писать такие отчеты.

2. Регистр сведений содержит:

— ряд измерений для хранения данных в разрезе аналитик;

— ресурсы:

— Алгоритм (тип строка) для хранения произвольного алгоритма контроля.

Ресурс Алгоритм — самое важное звено. Здесь можно описать любой алгоритм, который будет выполняться на сервере. Начиная от «Сообщить(«hello, world!)»», заканчивая сложными конструкциями как контроля, так и отчета о его выполнении, например, отправка на почту результата.

В общем модуле пара процедур, логика которых представлена ниже.

1. Сначала инициализация самого объекта проверки.

2. Поиск настроек контроля заполнения объекта в регистре.

3. Далее отработка алгоритмов проверки.

В самом алгоритме вы можете обращаться к самому объекту и менять его, используя переменную Источник.

А также можно корректировать текст, который увидит пользователь: переменная ТекстОшибки.

Вот собственно и всё.

Разработка выполнена на платформе 8.3.12.1790.

Внимание!

1. Если вы загружаете демо-базу, то можете взять конфигурацию оттуда, и загружать отсюда конфигурацию не надо! Конфы идентичны.

2. Будьте внимательны при объединении. Справочники объединять не надо! Они использованы для примера. Идентификаторы объектов метаданных — справочник из БСП, он должен быть у вас в конфе. Без него решение необходимо дорабатывать.

Доброго времени суток, уважаемые коллеги! В этой статье приведен реальный пример реализации переноса изменений конфигурации Бит. Автотранспорт (3.0.80.36/3.0.4.55) в расширение конфигурации и установка конфигурации под «замок» с возможностью обновления. Также показано, как решить возникшие проблемы по ходу переноса. Давайте разберёмся!

• Перечень основных шагов при переносе доработок конфигурации в расширение
• Копирование целого объекта из конфигурации в расширение
• Настройка связей параметров выбора для отбора по владельцу
• Установка проверки заполнения реквизита в расширении
• Перенос констант в расширение
• Добавление команды для формирования документа на основании
• Ввод на основании нескольких документов
• Описание обработки переноса данных
• Добавление дополнительных отчетов в расширение
• Демонстрация добавления и удаления расширения 1С
• Демонстрация доработок, перенесенных в расширение

Перечень основных шагов при переносе доработок конфигурации в расширение

1. Сравнить основную конфигурацию с конфигурацией поставщика. Как это сделать посмотрите здесь.
2. Посмотреть поддерживает ли режим совместимости возможность использования расширений? С версии платформы 8.3.11 появилась эта возможность. Нужно установить этот режим совместимости, если текущая версия ниже. 
3. Создать новое расширение конфигурации и установить префикс для этого расширения. Назначение: Адаптация. 
4. Добавить в расширение все структуры необходимые для хранения данных, которые отличаются от конфигурациии поставщика. Также для правильной работы расширения нужно будет заимствовать все необходимые объекты конфигурации. На этом шаге могут возникать разные ситуации, которые будут препятствовать переносу. Некоторые описаны начиная со следующего подзаголовка. На этом шаге расширение конфигурации уже должно быть готово. Как установить готовое расширение можно посмотреть на видео ниже.
5. Создать обработку для переноса данных из старых структур, которые были в основной конфигурации, в новые структуры, которые были созданы при помощи расширений. Некоторое описание обработки можно посмотреть в подзаголовке, а скачать её можно по ссылке в конце статьи.
6. Перенести данные. 
7. Удалить старые данные из конфигурации в правильном порядке. Это значит, что нужно сначала удалить объекты, в которых есть ссылки на другие объекты. Например, в документе есть реквизит с типом справочник Номенклатура. Сначала удалить этот реквизит, а затем и сам справочник Номенклатура.
8. Вернуть изменённые объекты конфигурации обратно на замок, установив для объектов правило поддержки Объект поставщика не редактируется.
9. Конфигурация — Поддержка — Настройка поддержки.
10. Снова выполнить сравнение с конфигурацией поставщика. Кнопка «Сравнить, обьединить».
11. Выставить в поле «Фильтр» значение «Нет фильтра».
12. Найти нужный объект в дереве, нажать в правом углу кнопку «Изменить» и выбрать правило «Объект поставщика не редактируется». И подобным образом для всех объектов, у которых раньше была снята поддержка. 

Копирование целого объекта из конфигурации в расширение

При копировании целого объекта из конфигурации в расширение может появится сообщение:

ОБНАРУЖЕНЫ НЕРАЗРЕШИМЫЕ ССЫЛКИ:

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

Если нужно добавить новые реквизиты на форму, то сначала нужно заимствовать эту форму и открыть её, затем перейти в правую панель с реквизитами. Основной реквизит формы (Объект) будет выделен серым. Чтобы заимствовать объект нужно в контекстном меню выбрать «Добавить в расширение», после этого основной реквизит формы (Объект) будет выделен черным.

Чтобы были видны реквизиты документа в модуле объекта расширения, например Контрагент или ВидОперации нужно эти реквизиты заимствовать в расширение. Иначе будет выдаваться такая ошибка:

{ЗаказНаТехнику Документ.СписаниеСРасчетногоСчета.МодульОбъекта(11,6)}: Переменная не определена (ВидОперации)

Если нужно на форме документа расширения добавить глобальную команду, то сначала нужно заимствовать эту команду в расширение и указать в ее свойствах «Тип параметра команды», как это показано в подзаголовке. Если, например, это документ СчетНаОплатуПокупателю, то параметром будет ДокументСсылка.СчетНаОплатуПокупателю соответственно. Если есть картинка к команде, то нужно заимствовать и её.

Настройка связей параметров выбора для отбора по владельцу

В существующем расширении реализована возможность отбора по владельцу для реквизита Заказ_ИсполнительДоговор документа бит_мат_ЗаказНаТехнику. Чтобы поле Владелец и другие стандартные реквизиты подчиненного справочника ДоговорыКонтрагентов (в данной конфигураци) отобразились в поле «Связи параметров выбора» нужно, заимствовать справочники Контрагенты и ДоговорыКонтрагентов в расширение. Потом отметить для справочника ДоговорыКонтрагентов свойство Владельцы как контролируемое. 

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

Установка проверки заполнения реквизита в расширении

В документе (бит_мат_ЗаказНаТехнику) в табличной части (ТребованияКТехнике) есть реквизит Техника со свойством “Проверка заполнения”, значение которого установлено как “Выдавать ошибку”, а нужно для него в расширении проставить значение “Не проверять”. Хотя этот реквизит перенесен в расширение, его свойства недоступны для редактирования. К сожалению, далеко не все свойства реквизитов документа являются расширяемыми. Но существует программное изменение значений свойств в расширении.

Хотя и невозможно поменять свойство “Проверка заполнения” в расширении у заимствованного реквизита, но можно изменить обработку ОбработкаПроверкиЗаполнения() в модуле объекта через расширение, так чтобы реквизит, даже не заимствованный, не проверялся. Вот, что можно написать:

&После("ОбработкаПроверкиЗаполнения")
Процедура Заказ_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
	ИндексПоляТехника = ПроверяемыеРеквизиты.Найти("ТребованияКТехнике.Техника");
	Если ИндексПоляТехника <> Неопределено Тогда
		ПроверяемыеРеквизиты.Удалить(ИндексПоляТехника);
	КонецЕсли;
КонецПроцедуры

Перенос констант в расширение

В конфигурации были добавлены две константы (бит_Номенклатура и НоменклатурнаяГруппа). Нужно было их перенести в расширение, но к сожалению, объекты Константы в расширении можно создавать только на платформе 8.3.16 и выше. Данная конфигурация не поддерживала режим совместимости 8.3.16. Поэтому было решено создать регистр сведений (Заказ_Константы) и хранить значение констант там, а для получения значений констант нужно использовать функцию общего модуля ЗаказНаТехнику. Эта функция возвращает структуру со всеми значениями констант, сохраненных в ресурсах регистра. Вот код этой функции:

Функция ПолучитьКонстанты() Экспорт
	Результат = Новый Структура();
	Результат.Вставить("бит_Номенклатура", Справочники.Номенклатура.ПустаяСсылка()) ;
	Результат.Вставить("НоменклатурнаяГруппа", Справочники.НоменклатурныеГруппы.ПустаяСсылка());
	Запрос = Новый Запрос;
	Запрос.Текст = 
	"ВЫБРАТЬ
	|   Заказ_Константы.бит_Номенклатура КАК бит_Номенклатура,
	|   Заказ_Константы.НоменклатурнаяГруппа КАК НоменклатурнаяГруппа
	|ИЗ
	|   РегистрСведений.Заказ_Константы КАК Заказ_Константы";
	
	РезультатЗапроса = Запрос.Выполнить();
	
	Выборка = РезультатЗапроса.Выбрать();
	
	Пока Выборка.Следующий() Цикл
		ЗаполнитьЗначенияСвойств(Результат, Выборка);
	КонецЦикла;
	Возврат Результат;
КонецФункции // ПолучитьКонстанты()

Добавление команды для формирования документа на основании

В конфигурации для документа РеализацияТоваровУслуг добавили возможность его ввода на основании документа бит_мат_ЗаказНаТехнику, а это значит, что стандартный реквизит ВводитсяНаОсновании документа РеализацияТоваровУслуг изменился. Чтобы сохранить возможность ввода документа РеализацияТоваровУслуг нужно:

• В расширении в разделе «Общие -> Общие команды«, создать новую команду. 
• Дать название, например, «Заказ_РеализацияТоваровУслугСоздатьНаОсновании«. 
• Группу у команды указать: «Командная панель формы.Создать на основании».
• Тип параметра команды: Ссылки тех документов, в которых появится новая строка в подменю ВводаНаОсновании. В данном случае «ДокументСсылка.битматЗаказНаТехнику«.
• Режим использования параметра: «Одиночный». Теперь в меню документа битматЗаказНаТехнику появится новая команда ввода на основании.

Теперь в меню документа битматЗаказНаТехнику появится новая команда ввода на основании. В модуле команды в процедуре ОбработкаКоманды написать код, который будет делать ввод нового документа на основании:

&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
	СтрДанные = Новый Структура("Основание", ПараметрКоманды);
	ПараметрыФормы = Новый Структура("ЗначенияЗаполнения", СтрДанные);
	
	ОткрытьФорму("Документ.РеализацияТоваровУслуг.ФормаОбъекта", ПараметрыФормы, 
	ПараметрыВыполненияКоманды.Источник, ПараметрыВыполненияКоманды.Уникальность, 
	ПараметрыВыполненияКоманды.Окно, ПараметрыВыполненияКоманды.НавигационнаяСсылка);
КонецПроцедуры

И еще, чтобы уже все работало в расширении после исполнения обработки заполнения Реализации добавить код с использованием аннотации ИзменениеИКонтроль (Вызвать вместо (с контролем)): 

&ИзменениеИКонтроль("ОбработкаЗаполнения")
Процедура Заказ_ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
	...
			#Вставка
			ИначеЕсли ТипДанныхЗаполнения = Тип("Структура")
				И ДанныеЗаполнения.Свойство("Основание")
				И ТипЗнч(ДанныеЗаполнения.Основание) = Тип("ДокументСсылка.бит_мат_ЗаказНаТехнику") Тогда				
				ДокументОснование = ДанныеЗаполнения.Основание;			
			#КонецВставки
			
	...
КонецПроцедуры

Ввод на основании нескольких документов

Чтобы можно было передавать сразу несколько документов в списке и создавать на их основе одну реализацию можно сделать следующее. Создать команду формы СоздатьНаОснованииРеализацияТоваровУслуг и расположить кнопку этой команды на форме списка в группе ГруппаГлобальныеКоманды и скрыть видимость этой кнопки. В списке документа в обработчике события ПриСозданииНаСервере переопределить команду, чтобы она появилась в ранее сформированной группе «Командная панель формы. Создать на основании»: 

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	...
		// Переопределим команду меню формы
		НазваниеКомандыФормы = "ФормаОбщаяКомандаЗаказ_РеализацияТоваровУслугСоздатьНаОсновании";
		ГруппаСоздатьНаОсновании = Элементы.ГруппаГлобальныеКоманды.ПодчиненныеЭлементы.Найти("ФормаСоздатьНаОсновании");
		Если ГруппаСоздатьНаОсновании <> Неопределено Тогда
			КнопкаСозданиеРеализации = ГруппаСоздатьНаОсновании.ПодчиненныеЭлементы.Найти(НазваниеКомандыФормы);
			Если КнопкаСозданиеРеализации <> Неопределено Тогда	
				КнопкаСозданиеРеализации.Видимость = Ложь;
				Элементы.ФормаСоздатьНаОснованииРеализацияТоваровУслуг.Видимость = Истина;
				Элементы.Переместить(Элементы.ФормаСоздатьНаОснованииРеализацияТоваровУслуг, 
										ГруппаСоздатьНаОсновании, КнопкаСозданиеРеализации);
	 		КонецЕсли; 
		КонецЕсли;
	
		// Переопределим команду контекстного меню
	        НазваниеКомандыФормы = "СписокКонтекстноеМенюОбщаяКомандаЗаказ_РеализацияТоваровУслугСоздатьНаОсновании";
		ГруппаКонтекстноеМенюСоздатьНаОсновании = 
		Элементы.Список.КонтекстноеМеню.ПодчиненныеЭлементы.Найти("СписокКонтекстноеМенюСоздатьНаОсновании");
		Если ГруппаКонтекстноеМенюСоздатьНаОсновании <> Неопределено Тогда
			КомандаСоздатьНаОсновании = 
			ГруппаКонтекстноеМенюСоздатьНаОсновании.ПодчиненныеЭлементы.Найти(НазваниеКомандыФормы);
			Если КомандаСоздатьНаОсновании <> Неопределено Тогда
			
				КомандаСоздатьНаОсновании.Видимость = Ложь;
				Элементы.СписокКонтекстноеМенюСоздатьНаОснованииРеализацияТоваровУслуг.Видимость = Истина;
				Элементы.Переместить(Элементы.СписокКонтекстноеМенюСоздатьНаОснованииРеализацияТоваровУслуг, 
										ГруппаКонтекстноеМенюСоздатьНаОсновании, КомандаСоздатьНаОсновании);
			КонецЕсли; 
		КонецЕсли;
		
	...
		
		#Область СлужебныеПроцедурыИФункции
		
		&НаКлиенте
		Процедура СоздатьНаОсновании(Команда)
			ВыделенныеСтроки = Элементы.Список.ВыделенныеСтроки;
			Если ТипЗнч(ВыделенныеСтроки) = Тип("Массив") Тогда		
				Если ВыделенныеСтроки.Количество() > 0 Тогда
				
					СтрДанные = Новый Структура("Основание", Новый ФиксированныйМассив(ВыделенныеСтроки));
					ПараметрыФормы = Новый Структура("ЗначенияЗаполнения", СтрДанные);
					
					ОткрытьФорму("Документ.РеализацияТоваровУслуг.ФормаОбъекта", ПараметрыФормы, ЭтотОбъект);
		
				КонецЕсли; 
			КонецЕсли; 
		КонецПроцедуры
		
		#КонецОбласти
		
	...
КонецПроцедуры

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

Как это будет сделано зависит от задачи, которую поставит заказчик. Может быть он захочет, чтобы из нескольких документов списка создавался один документ РеализацияТоваровУслуг, а может захочет, чтобы формировалось столько же документов РеализацияТоваровУслуг, сколько было выделено в списке. Любая постановка задачи от заказчика ложится на плечи разработчика. В данном, конкретном случае, нужно было сделать только для одного документа, все выше это как пример для тех, кому нужно реализовать с несколькими документами.

Описание обработки переноса данных

Обработка переносит данные из старых структур, которые были в основной конфигурации, в новые структуры, которые были созданы при помощи расширений. Её следует запускать, только после того, как будут добавлены все данные в расширение или когда уже готовое расширение будет добавлено в конфигурацию. Каждый разработчик создаёт такую обработку и под те структуры данных, которые создал в расширении. Для данного расширения создана своя обработка, которую можно скачать по ссылке.

Если говорить об обработке для данного расширения, то ещё с помощью этой обработки были устранены проблемы, связанные с дублированием данных в регистрах сведений ДвоичныеДанныеФайлов и ФайлыВРабочемКаталоге. Дело в том, что разработчик, изменил определяемый тип ПрисоединенныйФайл, добавив к нему новый тип СправочникСсылка.битматЗаказНаТехникуПрисоединенныеФайлы. Если просто изменить определяемый тип, убрав оттуда лишний тип и попытаться сохранить конфигурацию базы данных, то это не получится, так как возникнет такая ошибка:

Записи регистра сведений стали не уникальными: ДвоичныеДанныеФайлов

ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями

Дело в том, что у этих двух регистров измерение Файл имеет определяемый тип ПрисоединенныйФайл. Когда происходит удаление одного из типов в определяемом типе ПрисоединенныйФайл, то некоторые записи в этих регистрах становятся дублирующими, так как раньше, до удаления типа, в измерении Файл присутствовали элементы справочника бит_мат_ЗаказНаТехникуПрисоединенныеФайлы, а теперь там появились значения Null. В обработке реализован механизм, который устраняет эту проблему.

К сожалению, на момент написания статьи, система 1С:Предприятие не поддерживает ОпределяемыйТип. Только начиная с версии «1С:Предприятие 8.3.20», расширения будут поддерживать изменение определяемых типов.

Кроме того, в документе бит_мат_ЗаказНаТехнику в реквизите ОтветственноеЛицо был изменён тип. Раньше был СправочникСсылка.ФизическиеЛица, а стал СправочникСсылка.Пользователи. Поэтому в расширение был добавлен новый реквизит Заказ_ОтветственноеЛицо. Чтобы перенести данные в новый реквизит в обработке был сформирован определенный механизм.

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

Добавление дополнительных отчетов в расширение

Для получения сводной информации о движениях в новом регистре накопления бит_ВзаиморасчетыСКонтрагентом были созданы два отчета. Чтобы перенести эти отчеты нужно было сначала сохранить их в расширение, потом менять запрос СКД. Если так не сделать, а изменять их как внешние отчеты, то при открытии схемы компоновки данных будет выдаваться ошибка о невозможности найти некоторые данные. Находясь в расширении отчет видит структуры данных, как конфигурации, так и расширения. Какую информацию показывают эти два отчета можно посмотреть на видео ниже.

Демонстрация доработок, перенесенных в расширение

Конечно, здесь опубликовано не все, что есть в этом расширении конфигурации Бит.Автотранспорт для управления взаимоотношениями с контрагентами. Но вы можете увидеть, да и опробовать само это расширение, если скачаете его по этой ссылке.

Содержание:

1.       Свойство 1С «Проверка заполнения»

2.       Процесс проверки заполнения реквизита

Приветствую, коллеги! В данной статье я расскажу, как проводить программную проверку заполнения реквизита в режиме конфигуратора в 1С. Для начала мы рассмотрим общие понятия, после чего будет показан пример программного кода с комментариями. Также я расскажу, как проводить проверку на заполнение реквизита при помощи специального свойства и в каком случае это работает лучше, чем программная проверка. Всё описанное будет проиллюстрировано на вполне конкретном примере.  

1.    Свойство 1С «Проверка заполнения»

Чтобы проверить заполнение реквизита в 1С используется специальное свойство – Проверка заполнения. Для всех объектов метаданных, которые имеют типы, а также для реквизитов, которые выступают в стандартном формате, и таблиц, которые обязательно должны быть заполнены, для свойства «Проверка заполнения» должно быть определено значение «Выдавать ошибку».

В некоторых случаях проводить документацию, в которой не заполнены значения в реквизитах и таблицах – не является уместным, так как во время учётов документ не будет иметь отображения. Как пример, рассмотрим документ «Заказ клиента», по сути – это запрос клиента для поставки некоторой продукции в некотором количестве. Согласно определению, не сложно понять, что документ, в котором не заполнены обязательные реквизиты «Клиент» и таблица «Товары» не является корректным и в свойстве «Проверка заполнения» нужно выставить «Выдавать ошибку».

Во время установки свойства «Проверка заполнения» обязательно опираться на то, что все возможные ограничения и сверки нужно прописывать в метаданных внутри конфигурации. Так что когда хоть один из возможных вариантов требует заполнения всех реквизитов, свойство «Проверка заполнения» будет установлено в «Выдавать ошибку». В случае отсутствия обязательных к заполнению реквизитов подобные сценарии должны быть прописаны внутри обработчика «ОбработкаПроверкиЗаполнения».

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

2.    Процесс проверки заполнения реквизита

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

Проверка по заполнению реквизитов в 1С происходит в обработчике «ОпработкаПроверкиЗаполнения()». Данный обработчик необходимо разместить внутри модуля соответствующего объекта. Его можно вызвать автоматически, когда проводим документацию или сохраняем форму.

Для проверки необходимо запустить модуль документа «ОказаниеУслуги» и поместить в него следующую процедуру:

Рис. 1 Осуществление проверки заполнения реквизита в 1С

Теперь рассмотрим, что именно происходит в данной процедуре.

В начале нам нужно найти и получить реквизит из части таблицы «НаборСвойств», которая находится в массиве «ПроверяемыеРеквизиты». Данный массив будет передан к самому обработчику – в нём и содержатся те реквизиты, которые подлежат проверке. Для всех реквизитов внутри данного реквизита нужно выставить свойство «Проверка заполнения» для значения «Выдавать ошибку». В случае, если он будет распознан и найден, нужно будет удалить его, ведь проверка заполнения реквизитов будет выполняться полностью вручную.

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

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

Также вместо «ПереченьНоменклатуры» и «ВидНоменклатуры» можно использовать запросы.

Специалист компании «Кодерлайн»

Айдар Фархутдинов

Механизм проверки заполнения позволяет автоматически проверить, заполнены ли указанные реквизиты объекта (см. Как перед записью накладной проверить, что реквизит Поставщик заполнен?). Такая проверка выполняется при интерактивном вводе объекта, перед его записью.

При этом вызывается следующая последовательность событий:

Таким образом разработчик может влиять на стандартную проверку заполнения, выполняемую платформой. 

Для этого у него есть два события. Одно событие – ОбработкаПроверкиЗаполненияНаСервере – можно обработать в модуле формы. Другое событие – ОбработкаПроверкиЗаполнения – можно обработать в модуле прикладного объекта.

У формы, как правило, есть основной реквизит (редактируемый объект) и могут быть реквизиты, не относящиеся к редактируемому объекту, а являющиеся лишь частью формы:

Поэтому серверное событие формы ОбработкаПроверкиЗаполненияНаСервере предназначено для проверки заполнения тех реквизитов формы, которые не относятся к редактируемому объекту. Это данные только формы, у формы могут быть свои причины и алгоритмы для проверки этих данных.

Напротив, событие объекта ОбработкаПроверкиЗаполнения предназначено для для того, чтобы проверить реквизиты основного реквизита формы.

Обработчики обеих событий имеют параметр ПроверяемыеРеквизиты, в который платформа передает массив имен тех реквизитов, которые подлежат проверке. Если после выхода из обработчика в этом массиве все еще останутся какие-то имена реквизитов — платформа выполнит автоматическую проверку оставшися реквизитов.

Поэтому существует несколько сценариев того, как разработчик может встроить свой алгоритм в механизм проверки заполнения:

1. самостоятельно проверить заполненность всех реквизитов и очистить массив ПроверяемыеРеквизиты, чтобы платформа не выполняла их проверку,
2. проверить часть реквизитов самостоятельно, удалить их из массива ПроверяемыеРеквизиты, а оставшиеся оставить на проверку платформе,
3. добавить в массив ПроверяемыеРеквизиты какие-то реквизиты, чтобы платформа проверила и их тоже,
4. вообще отказаться от проверки заполненности реквизитов, очистив массив.

Все эти сценарии реализуются довольно просто.

Например, чтобы самостоятельно проверить заполненность реквизитов, можно выполнить следующий код:

Если Поставщик = Справочники.Поставщики.ПустаяСсылка() Тогда
   Сообщение = Новый СообщениеПользователю;
   Сообщение.Текст = "Необходимо заполнить поставщика!";
   Сообщение.Поле  = "Поставщик";
   Сообщение.УстановитьДанные(ЭтотОбъект);
   Сообщение.Сообщить();

   Отказ = Истина;

КонецЕсли;

// Проверка остальных реквизитов
// ...
// Очистить массив проверяемых реквизитов, чтобы платформа
// не выполняла их автоматическую проверку.

ПроверяемыеРеквизиты.Очистить(); 

Чтобы проверить лишь часть реквизитов, можно выполнить такой код:

Если Поставщик = Справочники.Поставщики.ПустаяСсылка() Тогда
   Сообщение = Новый СообщениеПользователю;
   Сообщение.Текст = "Необходимо заполнить поставщика!";
   Сообщение.Поле  = "Поставщик";
   Сообщение.УстановитьДанные(ЭтотОбъект);
   Сообщение.Сообщить();

   Отказ = Истина;

   // Удалить поставщика из массива проверяемых реквизитов.
   ИндексПоляПоставщик = ПроверяемыеРеквизиты.Найти("Поставщик");

   Если ИндексПоляПоставщик <> Неопределено Тогда
      ПроверяемыеРеквизиты.Удалить(ИндексПоляПоставщик);

   КонецЕсли;

КонецЕсли;

Добавить в массив проверяемых реквизитов еще один реквизит можно следующим образом:

ПроверяемыеРеквизиты.Добавить("Комментарий"); 

А очистить массив проверяемых реквизитов, чтобы ничего не проверять ни самому, ни платформе, можно так:

ПроверяемыеРеквизиты.Очистить(); 

Вторым параметром в обработчиках этих событий является параметр Отказ.

Если ему присвоить значение Истина, то после выхода из обработчика дальнейшая запись объекта будет отменена. Таким образом этот параметр нужно устанавливать в значение Истина тогда, когда ваш алгоритм приходит к выводу, что реквизит не заполнен. В этом случае запись объекта выполнена не будет.

Прочитай, хотя бы, Митичкина «Разработка в системе 1С:Предприятие 8». Волшебник