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

26.02.22

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

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Демо база
.dt 78,46Mb ver:v1.0.1
0
0 Скачать (1 SM) Купить за 1 850 руб.
Конфигурация
.cf 82,72Kb ver:v1.0.1
1
1 Скачать (1 SM) Купить за 1 850 руб.
Расширение
.cfe 13,38Kb ver:v1.0.1
1
1 Скачать (1 SM) Купить за 1 850 руб.

Оглавление

«Грязные данные». 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.

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

См. также

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

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

12000 руб.

02.09.2020    171602    960    403    

924

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

Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются серверные и файловые базы, управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя. Решение в Реестре отечественного ПО

8400 руб.

20.08.2024    14191    108    46    

107

Инструментарий разработчика Программист Платформа 1С v8.3 1C:Бухгалтерия Платные (руб)

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

9360 руб.

17.05.2024    27213    96    48    

137

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

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

22200 руб.

06.10.2023    17231    43    15    

75

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

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

15000 руб.

10.11.2023    11876    45    27    

67

SALE! %

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

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

4800 3840 руб.

14.01.2013    191131    1152    0    

920

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

Разработка Конструктор автоматизированных рабочих мест "Конструктор АРМ" реализована в виде расширения и является универсальным инструментом для создания АРМ любой сложности в пользовательском режиме.

3600 руб.

27.12.2024    1102    2    0    

5

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

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

5000 руб.

07.02.2018    104105    244    100    

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

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


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

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

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

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

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

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

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