Работа с данными заполнения

26.02.22

Разработка - Инструментарий разработчика

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

Скачать исходный код

Наименование Файл Версия Размер
Демо база
.dt 78,46Mb
0
.dt v1.0.1 78,46Mb Скачать
Конфигурация
.cf 82,72Kb
1
.cf v1.0.1 82,72Kb 1 Скачать
Расширение
.cfe 13,38Kb
1
.cfe v1.0.1 13,38Kb 1 Скачать

Оглавление

«Грязные данные». 1

Проверка заполнения данных. 2

Подсистема «Работа с данными заполнения». 3

Описание. 3

Заполнение структуры проверки и очистки. 4

Проверка и очистка. 4

Проверка дублей. 4

Работа с ошибками заполнения. 4

Стенд. 5

Описание. 5

ОбработкаПроверкиЗаполнения. 5

Сценарии. 5

Поставка


. 5

«Грязные данные»

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

Данные объекта требуют предварительной проверки и очистки перед использованием. Например, рассмотрим справочник Контрагенты. Контрагентами могут выступать физические и юридические лица. Состав реквизитов справочника может частично различаться: для физлиц не используется КПП, а для юрлиц - данные документов, удостоверяющие личность. Если так получилось, что при заполнении данных вначале мы использовали карточку физлица, а перед окончанием ввода передумали и стали заполнять данные юрлица, то возможна ситуация, когда в БД будут записаны для юрлица также данные и физлица. Это и есть основной пример появления "грязных данных".

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

При анализе в отчетах также требуется знать особенности объектов, чтобы получать "чистые данные". Так, например, в реализации заявки на расходование по внутренним операциям реквизит Контрагент не используется. Однако если значение этого реквизита впоследствии оказывается в регистрах, по которым строятся отчеты, то наличие "грязных данных" может привести к неверному результату уже в отчетных данных.

Рассмотрим еще один пример с табличной частью. Пусть в табличной части заявки на расходование денежных средств указана статья с аналитикой. При этом одни статьи могут иметь аналитику, а другие - нет. Пусть пользователь вначале ввел в строку 1 статью с аналитикой и заполнил её. Затем пользователь выбрал другую статью, уже без дополнительной аналитики. Возможности условного оформления могут с легкостью скрыть от пользователя “грязные данные”, однако они никуда не делись. Мало того, что эти данные могут быть записаны, они еще могут привести к ошибке при проверке на дублирование строк. Проверка на дубли опирается на введенные данные, однако если «грязные данные» не очистить, то эти данные также будут учтены и результат может быть неверным.

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

Проверка заполнения данных

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

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

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

Еще следует учесть, что проверка заполнения происходит вне транзакции. Поэтому, если логика проверки требует соблюдение транзакционной целостности, то располагать такую проверку следует в обработчиках: ПередЗаписью, ПриЗаписи, ОбработкаПроведения (для документов).

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

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

Подсистема «Работа с данными заполнения»

Описание

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

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

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

Заполнение структуры проверки и очистки

Реквизиты шапки и таблицы

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

В качестве реквизита могут выступать: реквизиты шапки, табличные части. Указанные таблицы в составе обязательных реквизитов будут проверены на наличие строк. Если таблица попадает в список Исключенные, то она будет очищена.

Таблицы и строки

Структура ПроверяемыеРеквизитыТабличныхЧастей представляет собой список описаний таблиц. Имя таблицы соответствует ключу элемента структуры, а в значении содержится массив проверяемых строк. Каждый элемент проверяемой строки представляет собой вложенную структуру двух массивов: ПроверяемыеРеквизиты, ИсключаемыеРеквизиты.

Проверка и очистка

Реализацию обработчика «ОбработкаПроверкиЗаполнения» можно представить в виде последовательности вызова процедур:

  1. ЗаполнитьПроверяемыеРеквизиты
  2. ПроверитьЗаполнение
  3. ОчиститьДанные
  4. ПроверитьДублиСтрок

Проверка дублей

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

Настройка сообщений ошибок не предусмотрена. Подсистема при обнаружении дублей формирует заголовок вида: "В таблице ... обнаружены повторы строк по значению поля (ей) ...", и сообщения вида: «Значения ... повторены в строках: X, Y, Z».

Работа с ошибками заполнения

С ошибками можно поступить по разному: вывести в сообщения пользователю или запомнить в структуре объекта Дополнительные свойства. Второй вариант, назовем его «тихий» удобен, когда результат проверки передается внешнему алгоритму.

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

Стенд на базе документа _ДемоРеализацияТоваров

Описание

Пример работы с подсистемой можно посмотреть в демоконфигурации БСП на примере документа _ДемоРеализацияТоваров. В документе реализован обработчик проверки заполнения реквизитов шапки и табличной части. Дубли проверяются по уникальности значений поля Номенклатура. Поле табличной части "ДокументПоступления" должен быть заполнен в зависимости от заполненного артикула в номенклатуре.

ОбработкаПроверкиЗаполнения

 

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

 
 ПолучитьСтруктуруПроверяемыхРеквизитовСтрокиТовары
 
 ЗаполнитьПроверяемыеРеквизиты
 
 ОбработкаПроверкиЗаполнения

 

Сценарии

Очистка данных поля ДокументПоступления

Контекст: в табличной части 2 строки. В 1-ой строке использована номенклатура без артикула, во 2-ой – с артикулом. Артикул не является реквизитом табличной части. Поле «Документ поступления» заполнено во всех строках.

Сценарий: Я как пользователь хочу, чтобы в строках номенклатуры без артикула поле «Документ поступления» было очищено.

  1. Пользователь вызывает команду Провести
  2. Система очищает поле «Документт поступления» в 1-ой строке

Контроль заполнения поля ДокументПоступления

Сценарий: Я как пользователь хочу, чтобы в строках номенклатуры с артикулом поле «Документ поступления» было заполнено.

  1. Пользователь вызывает команду Провести
  2. Система проверяет заполнение поля «Документ поступления» во 2-ой строке
  3. Если поле не заполнено, то система выдает сообщение об ошибке и не проводит документ

Изображение выглядит как текстАвтоматически созданное описание

Повтор по полю Номенклатура

Сценарий: Я как пользователь хочу, чтобы в строках номенклатура была уникальной.

  1. Пользователь вызывает команду Провести
  2. Система проверяет повтор по полю Номенклатура
  3. Для строк с одинаковыми значениями поля Номенклатура система выдает сообщение об ошибке дублирования и не проводит документ

Изображение выглядит как текстАвтоматически созданное описание

Поставка

Зависимости: БСП, МодельЗапроса. Платформа 8.3.18 (8.3.18.1520).

Проект выложен на github.

ОбработкаПроверкиЗаполнения ПроверитьЗаполнение ПроверкаЗаполнения

См. также

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    124637    681    389    

732

Infostart PrintWizard

Пакетная печать Печатные формы Инструментарий разработчика Платформа 1С v8.3 Запросы 1С:Зарплата и кадры бюджетного учреждения 1С:Конвертация данных 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Платные (руб)

Инструмент, позволяющий абсолютно по-новому взглянуть на процесс разработки печатных форм. Благодаря конструктору можно значительно снизить затраты времени на разработку печатных форм, повысить качество и "прозрачность" разработки, а также навести порядок в многообразии корпоративных печатных форм.

18000 руб.

06.10.2023    7723    24    6    

42

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 руб.

10.11.2023    4240    12    2    

36

SALE! %

PowerTools

Инструментарий разработчика Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.

3600 2280 руб.

14.01.2013    178578    1083    0    

861

Многопоточность. Универсальный «Менеджер потоков» 2.1

Инструментарий разработчика Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

Восстановление партий или взаиморасчетов, расчет зарплаты, пакетное формирование документов или отчетов - теперь все это стало доступнее. * Есть желание повысить скорость работы медленных алгоритмов! Но... * Нет времени думать о реализации многопоточности? * о запуске и остановке потоков? * о поддержании потоков в рабочем состоянии? * о передаче данных в потоки и как получить ответ из потока? * об организации последовательности? Тогда ЭТО - то что надо!!!

5000 руб.

07.02.2018    99585    239    97    

298

[ЕХТ] Фреймворк для Расширений 1С

Инструментарий разработчика Платформа 1С v8.3 Управляемые формы Платные (руб)

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

3000 руб.

27.08.2019    18358    6    8    

40

Выполнение произвольного кода или запроса с параметрами через Web-сервис (замена COM-подключений)

Инструментарий разработчика Обмен между базами 1C Платформа 1С v8.3 Платные (руб)

В процессе работы в 1С часто возникает потребность получить данные из другой базы.  Обычно это делается через COM-соединение, и время выполнения запроса при этом оставляет желать лучшего. В данной публикации представлено универсальное решение, позволяющее практически моментально выполнить произвольный код или запрос с параметрами в другой информационной базе через Web-сервис.

2400 руб.

24.09.2019    23844    16    15    

33

1С HTML Шаблоны / HTML Templates

Инструментарий разработчика Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Быстрая и удобная обработка для работы с шаблонами HTML. Позволяет легко и быстро формировать код HTML.

2040 руб.

27.12.2017    28300    3    10    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. reset2 17 02.03.22 13:14 Сейчас в теме
Соответствующие обработчики есть как для модуля формы, так и для модуля объекта. Такое разделение проверки сделано с расчетом построения различной логики проверки для реквизитов формы и реквизитов объекта.

Мне такое разделение реализации на интерактивный и программный режим показалось не очень практичным.


1. Сценарий "Очистка данных поля ДокументПоступления"
- Провели документ с заполненными ДокументПоступления
- Очистили артикулы у номенклатуры
- Еще раз провели (через год)...
Итог: регистры поехали
В данном примере очистка поля (и проверка) должна как раз происходить на уровне формы (при изменении номенклатуры например), а лучше хранить Артикул в реквизите, если от него данные зависят.

2. Сценарий "Контроль заполнения поля ДокументПоступления"
Тоже самое:
- Провели документ с незаполненными ДокументПоступления
- Добавили артикулы у номенклатуры
- Документ перестал перепроводится

3. Сценарий "Повтор по полю Номенклатура"
Интересно, как поведут себя документы, после использования обработки "Замена дублей".
+
3. kalyaka 1056 02.03.22 14:00 Сейчас в теме
(1)
должна как раз происходить на уровне формы
Согласен. Если обобщить, то по нормальному проверка должна быть на уровне объекта. Такое решение, работа на уровне объекта, более технологичное и у меня уже есть наработки в этом направлении (см. мои статьи по MVC и управлению состоянием). В новом решении, которое я готовлю, к управлению состояниями будут добавлены также контроль и очистка данных.

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

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

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

Кстати одна из весомых причин в пользу "подтягивания" внешних данных - более простая реализация. Ведь если добавлять реквизиты, то нужно добавлять и механизмы их заполнения как в программном интерфейсе, так и в интерактивной форме.
+
2. Yashazz 4722 02.03.22 13:36 Сейчас в теме
Вообще, в значительной степени, защита логической и семантической правильности данных должна быть на уровне интерфейсов и форм. Очистка или автозаполнение одних полей в зависимости от других, итд. Нынешние формы не всегда "моно-объекты", скажем так, и эффект работы с ними комплексный. Кроме того, контекст и кэш форм содержит огромное количество того, что в любом другом месте придётся ещё получать повторно.
+
4. kalyaka 1056 02.03.22 14:05 Сейчас в теме
(2)Согласен, подобное решение я закладываю в новую версию подсистемы управление состоянием
+
Внимание! Тема сдана в архив