Оглавление
Подсистема «Работа с данными заполнения»
Заполнение структуры проверки и очистки
«Грязные данные»
В силу особенности организации хранения данных в реляционных БД объект, характеризуемый разным составом реквизитов, при записи часть данных может не использовать. Неиспользуемые реквизиты, содержащие значащие значения являются информационным шумом. Данные, содержащие информационный шум, будут приводить к ошибкам интерпретации и к дополнительным проверками в коде. В идеале правильно записанный объект содержит всю необходимую информацию, соответствующую его состоянию, «грязные данные» при этом приводятся к незначащим значениям.
Данные объекта требуют предварительной проверки и очистки перед использованием. Например, рассмотрим справочник Контрагенты. Контрагентами могут выступать физические и юридические лица. Состав реквизитов справочника может частично различаться: для физлиц не используется КПП, а для юрлиц - данные документов, удостоверяющие личность. Если так получилось, что при заполнении данных вначале мы использовали карточку физлица, а перед окончанием ввода передумали и стали заполнять данные юрлица, то возможна ситуация, когда в БД будут записаны для юрлица также данные и физлица. Это и есть основной пример появления "грязных данных".
В алгоритмах требуется дополнительно анализировать допустимый состав реквизитов объектов, что приводит к сильному связыванию кода. По сути в алгоритмах требуется дополнительно дублировать особенности реализации объектов, вместо того, чтобы просто пользоваться данными.
При анализе в отчетах также требуется знать особенности объектов, чтобы получать "чистые данные". Так, например, в реализации заявки на расходование по внутренним операциям реквизит Контрагент не используется. Однако если значение этого реквизита впоследствии оказывается в регистрах, по которым строятся отчеты, то наличие "грязных данных" может привести к неверному результату уже в отчетных данных.
Рассмотрим еще один пример с табличной частью. Пусть в табличной части заявки на расходование денежных средств указана статья с аналитикой. При этом одни статьи могут иметь аналитику, а другие - нет. Пусть пользователь вначале ввел в строку 1 статью с аналитикой и заполнил её. Затем пользователь выбрал другую статью, уже без дополнительной аналитики. Возможности условного оформления могут с легкостью скрыть от пользователя “грязные данные”, однако они никуда не делись. Мало того, что эти данные могут быть записаны, они еще могут привести к ошибке при проверке на дублирование строк. Проверка на дубли опирается на введенные данные, однако если «грязные данные» не очистить, то эти данные также будут учтены и результат может быть неверным.
Надеюсь, что соображения по приведенным примерам убедили Вас в важности очистки данных. В платформе есть стандартная возможность настройки проверки заполнения обязательных данных, однако нет никакого механизма по очистке исключенных. Также в платформе не предусмотрена стандартная возможность определить разные условия настройки заполнения для разных строк табличной части.
Проверка заполнения данных
Стандартно платформа выполняет проверку заполнения данных при интерактивном вызове команды проведения, старта бизнес-процесса - в зависимости от объекта и его настройки. Проверяются платформой те реквизиты, для которых в режиме конфигуратора указана настройка «Проверка заполнения» = "Выдавать ошибку". В неинтерактивном режиме вызвать проверку можно программно через вызов метода объекта ПроверкаЗаполнения(). Кроме того, в предопределенном обработчике можно переопределить состав проверяемых реквизитов. Однако нельзя задать разный состав реквизитов для разных строк табличной части.
Соответствующие обработчики есть как для модуля формы, так и для модуля объекта. Такое разделение проверки сделано с расчетом построения различной логики проверки для реквизитов формы и реквизитов объекта.
Мне такое разделение реализации на интерактивный и программный режим показалось не очень практичным. В своем решении я исхожу из того, что если проверка требуется, то она должна вызывается перед программной записью такая же как и при интерактивном вводе. Здесь я исхожу из того, что объект может быть составным, т.е. часть данных объекта может быть в составе других объектов, которые могут располагаться в реквизитах формы. Обработчик проверки объекта при этом должен также проверять и связанные данные на форме (как это сделать - тема отдельного рассмотрения).
Еще следует учесть, что проверка заполнения происходит вне транзакции. Поэтому, если логика проверки требует соблюдение транзакционной целостности, то располагать такую проверку следует в обработчиках: ПередЗаписью, ПриЗаписи, ОбработкаПроведения (для документов).
Согласно методическим указаниям фирмы 1С, проверку следует размещать для интерактивной проверки в обработчике ОбработкаПроверкиЗаполнения, а для особо критичных данных в обработчике события ПередЗаписью. Дело в том, что согласно тем же указаниям, обработчик проверки заполнения предназначен в первую очередь для проверки результата интерактивного заполнения пользователем, но для предотвращения ситуации программной записи некорректных данных следует располагать проверку наиболее критичных данных объекта в обработчике ПередЗаписью.
Сторонние алгоритмы должны перед программной записью объекта вызывать его проверку заполнения и уже по результату выполненной проверки определять ход дальнейшего выполнения. При этом та часть проверки, которая происходит вне транзакции, полностью определяется состоянием объекта, а та, которая в транзакции - определяется внешними данными.
Подсистема «Работа с данными заполнения»
Описание
Решение на базе подсистемы позволяет реализовать гибкую проверку как заполнения данных реквизитов, таблиц, реквизитов отдельных строк, так и очистку данных исключенных реквизитов.
В общем виде алгоритм работы с подсистемой следующий: в модуле объекта производится заполнение структуры проверяемых данных. На основании полученной структуры подсистема осуществляет очистку данных исключенных реквизитов и проверку обязательных для заполнения. По результату проверки формируется массив ошибок. В конце выполнения проверки заполнения можно на выбор вывести полученные ошибки в сообщении пользователю, либо сохранить в дополнительных данных объекта для передачи во внешний алгоритм.
Вся работа с подсистемой происходит в теле функции предопределенного обработчика ОбработкаПроверкиЗаполнения. Этот обработчик автоматически вызывается платформой в интерактивном режиме, а также может быть вызван программно косвенно через вызов метода объекта ПроверитьЗаполнение().
Заполнение структуры проверки и очистки
Реквизиты шапки и таблицы
Для начала работы необходимо получить массивы проверяемых и исключаемых реквизитов.
В качестве реквизита могут выступать: реквизиты шапки, табличные части. Указанные таблицы в составе обязательных реквизитов будут проверены на наличие строк. Если таблица попадает в список Исключенные, то она будет очищена.
Таблицы и строки
Структура ПроверяемыеРеквизитыТабличныхЧастей представляет собой список описаний таблиц. Имя таблицы соответствует ключу элемента структуры, а в значении содержится массив проверяемых строк. Каждый элемент проверяемой строки представляет собой вложенную структуру двух массивов: ПроверяемыеРеквизиты, ИсключаемыеРеквизиты.
Проверка и очистка
Реализацию обработчика «ОбработкаПроверкиЗаполнения» можно представить в виде последовательности вызова процедур:
- ЗаполнитьПроверяемыеРеквизиты
- ПроверитьЗаполнение
- ОчиститьДанные
- ПроверитьДублиСтрок
Проверка дублей
При наличии таблиц вероятно требуется проверка на наличие дублей строк. Проверка на дубли должна располагаться после проверки заполнения и очистки. Такой порядок обусловлен тем, что результат проверки зависит от заполнения и чистоты данных.
Настройка сообщений ошибок не предусмотрена. Подсистема при обнаружении дублей формирует заголовок вида: "В таблице ... обнаружены повторы строк по значению поля (ей) ...", и сообщения вида: «Значения ... повторены в строках: X, Y, Z».
Работа с ошибками заполнения
С ошибками можно поступить по разному: вывести в сообщения пользователю или запомнить в структуре объекта Дополнительные свойства. Второй вариант, назовем его «тихий» удобен, когда результат проверки передается внешнему алгоритму.
Для "тихого" режима текст ошибок сохраняется в дополнительном свойстве "ОшибкиЗаполнения". Массив ошибок также сохраняется в свойстве "Ошибки". Массив ошибок можно использовать для включения найденных ошибок в общий список ошибок, например, по списку обрабатываемых документов.
Стенд на базе документа _ДемоРеализацияТоваров
Описание
Пример работы с подсистемой можно посмотреть в демоконфигурации БСП на примере документа _ДемоРеализацияТоваров. В документе реализован обработчик проверки заполнения реквизитов шапки и табличной части. Дубли проверяются по уникальности значений поля Номенклатура. Поле табличной части "ДокументПоступления" должен быть заполнен в зависимости от заполненного артикула в номенклатуре.
ОбработкаПроверкиЗаполнения
Демо реализация обработчика со вспомогательными функциями представлена в спойлерах ниже:
Сценарии
Очистка данных поля ДокументПоступления
Контекст: в табличной части 2 строки. В 1-ой строке использована номенклатура без артикула, во 2-ой – с артикулом. Артикул не является реквизитом табличной части. Поле «Документ поступления» заполнено во всех строках.
Сценарий: Я как пользователь хочу, чтобы в строках номенклатуры без артикула поле «Документ поступления» было очищено.
- Пользователь вызывает команду Провести
- Система очищает поле «Документт поступления» в 1-ой строке
Контроль заполнения поля ДокументПоступления
Сценарий: Я как пользователь хочу, чтобы в строках номенклатуры с артикулом поле «Документ поступления» было заполнено.
- Пользователь вызывает команду Провести
- Система проверяет заполнение поля «Документ поступления» во 2-ой строке
- Если поле не заполнено, то система выдает сообщение об ошибке и не проводит документ
Повтор по полю Номенклатура
Сценарий: Я как пользователь хочу, чтобы в строках номенклатура была уникальной.
- Пользователь вызывает команду Провести
- Система проверяет повтор по полю Номенклатура
- Для строк с одинаковыми значениями поля Номенклатура система выдает сообщение об ошибке дублирования и не проводит документ
Поставка
Зависимости: БСП, МодельЗапроса. Платформа 8.3.18 (8.3.18.1520).
