Руководство по установке#
Установка#
Примечание
Модуль устанавливается совместно с основным приложением.
Подключите в метаданные проекта подсистемы:
..\Подсистемы\Проверка на наличие оснований в отказе\Уведомления ИЖС
Откройте метаданные проекта в Редакторе метаданных и проверьте на наличие ошибок.
Обновите метаданные на проекте (См. Как скачать протокол).
Убедитесь в наличии модуля
Module.ServiceCriteriaCheck
. Модуль уже присутствует, если вы получили пакет с дистрибутивами для проекта.Обновите основное приложение Geometa с помощью тега
install_ias
(См. Обновление и установка Системы с использованием Ansible).
Настройка#
Добавьте в Систему справочные значения, роль и каталог с реестрами для модуля с помощью скриптов из репозитория метаданных по пути ..\Подсистемы\Проверка на наличие оснований в отказе\Для установки\FullWfScript.
Положите xml в папку ../AppServer/appdata/plugins/CriteriaCheckSettings/. Каждому xml присвоийте имя согласно услуге. (См. XML и модуль на бэкенде)
На скриншоте xml представлены в качестве примера и могут не совпадать с метаданными и требуемыми проверками на проекте. Сконфигурируйте xml согласно интрукции. (См. Структура XML)

Конфигурирование#
Использование модуля для различных услуг#
При функционировании модуля проверки на наличие оснований в отказе в рамках услуги используется каскадная кнопка «Проверка на несоответствия» и вкладка с результатами проверок. Соответственно, чтобы использовать модуль для новой услуги, необходимо отобразить кнопку проверки и вкладку с результатами проверок в карточке этой услуги.
Для того, чтобы каскадная кнопка «Проверка на несоответствия» с выпадающим списком действий отображалась в карточке услуги, необходимо наличие xml с корректной структурой, с указанием алиаса по этой услуге. При этом для услуги должны быть разработаны через специализированный редактор метаданных и загружены в систему через конфигуратор все необходимые метаданные.
Настройка запрета редактирования карточек#
Для того, чтобы настроить запрет пользователю на редактирование карточек, используемых в модуле, необходимо воспользоваться разделом Роли проекта в конфигураторе системы. Перейти в роль, предназначенную для пользователей, работающих с услугой, по которой проводится проверка на несоответствие. И дать права на просмотр для типов «Результат проверки» и «Проверяемый критерий». Также необходимо дать права на редактирование для типа «Причины отказа», чтобы пользователю были видны причины несоответствия.
Услуга: Выдача уведомления для планируемого строительства:
роль - АРМ «Уведомления для ИЖС» (armIHB);
типы - Проверяемый критерий (ServiceCheckModuleComparableCriterion);
результат проверки (ServiceCheckModuleResult);
причины отказа (DocRefMismatchReasonType).
Метаданные#
Для корректной работы модуля проверки на наличие оснований в отказе, то есть для отображения в интерфейсе системы необходимых вкладок, карточек, полей и генерации соответствующих им таблиц, атрибутов в БД, необходимо внести изменения в метаданные, посредствам редактора метаданных и загрузки изменений через конфигуратор ПО Geometa.
Метаданные необходимые для корректной работы модуля#
На каждую карточку услуги, по которой предполагается использовать модуль проверок на несоответствие, добавляется вкладка «Результат проверок» с информацией о результатах всех проверок.
Для этого необходимо добавить логическую таблицу LT c указанием на физическую таблицу PT: D_SERVICE_CHECK_MODULE_RESULT (ServiceCheckModuleResultTable) и необходимыми для этой услуги полями, по аналогии с LT: Результат проверки (ServiceCheckModuleResult) (Услуга: Выдача уведомления для планируемого строительства).
Кроме того, в LT услуги добавляется секция с Section key - S: Результат проверок (CheckResult), в эту секцию добавляется атрибут MR: Проверки (CheckModuleResult) (поле с результатми проверок), для которого: Phisical table - PT: D_REL_CHECK_RESULT_SERVICE (RelCheckResultToServiceTable), Target – LT: Результат проверки (ServiceCheckModuleResult) (или другая подобная LT для Результата проверки), Owner column - D_REL_CHECK_RESULT_SERVICE.SERVICE_KEY, Target column - D_REL_CHECK_RESULT_SERVICE.CHECK_RESULT.
Особенность проверки пересечений с пространственными объектами#
Для проверки пересечений пространственных объектов используются поля с пространственной связью. В реакторе метаданных в скрытую секцию карточки объекта (логическую таблицу LT), добавляется скрытое поле с пространственной связью (SR). Для этого поля, указываются GLV (слой) и PV (физическое представление). Причем в PV добавляется sql скрипт, который формирует выборку объектов для проверки.
Пример скрипта для PV: V_GEO_HISTORIC_SETTLEMENT (GeoHistoricSettlementView):
/*+GEOSQL*/
select su.key,
su.date_insert,
su.date_update,
su.user_insert,
su.user_update,
su.full_name,
su.sys_status,
su.info_set_key,
su.srev,
su.erev,
su.la_spatial_unit_type_key,
typ.alias,
geo.owner_key,
geo.geoloc,
geo.geoloc_orig,
geo.geometrytype,
geo.numgeometries,
geo.npoints,
geo.linelength
from @schema@.d_su_zor su
join @schema@.D_GEO_ZOR geo ON su.key = geo.owner_key AND geo.sys_status=0
join @schema@.d_ref_la_spatial_unit_type typ on typ.key = su.la_spatial_unit_type_key and typ.sys_status = 0 and typ.alias = 'ZORHistoricSettlement'
join @schema@.d_ref_directory_simple dir on dir.key = su.zor_status and dir.sys_status = 0 and dir.alias = 'ZORStatusPr_1'
where su.sys_status = 0
XML и модуль на бэкенде#
Настройка критериев производится в XML, с которой взаимодествует модуль на бэкенде.
Доступна возможность проведения проверок для различных услуг системы. В зависимости от вида заявления выполняется сопоставление критериев и услуги, по которой запускается проверка. То есть сопоставление проверяемых критериев и услуги происходит по атрибуту «Вид заявления» заявления, связанного с рассматриваемой услугой. Если критерии для различных услуг расходятся, в случае, когда для разных регламентных услуг в системе используется одна и та же карточка услуги, то для каждой такой услуги заводится отдельный вид заявления.
Кроме того, для каждой регламентной услуги, то есть для каждого вида заявления, есть свой список причин отказа, который хранится в специальном справочнике в базе данных. Каждому проверяемому критерию для услуги ставится в соответствие одна из таких причин. Сопоставление со справочниками из БД, в том числе со справочником причин отказа, производится через alias, recordAlias.
Под каждую отдельную услугу создаются отдельные XML. В XML указываются критерии по услуге, кастомные сообщения и пр. В Приложении 1
приведена общая структура XML по проверке критериев для услуги Выдача уведомления для планируемого строительства, без детализации описания самих критериев, в Приложении 2
– для услуги Утверждение СРЗУ, в Приложении 3
– для услуги Предварительное согласование предоставления ЗУ.
Паттерны#
Для описания критериев проверки используются паттерны, причем сами паттерны описываются отдельно от критериев и зашиты в модуль на бэкенде.
Выделенные паттерны представляют из себя обобщенное правило и универсальны. Условием правильности выделения паттернов является то, что все критерии могут быть описаны каким-то одним из этих паттернов. Паттерны формируются исходя из положительного результата, а не отрицательного.
Паттерны могут быть касающиеся:
Текста (заполнено, не заполнено, равно, не равно);
Даты (заполнено, не заполнено, больше, меньше, равно);
Связей (сравнение объектов между которыми установлена связь);
Чисел (заполнено, не заполнено, больше, меньше, равно);
Файлов (наличие, отсутствие);
Пересечений пространственных объектов (наличие, отсутствие пересечений объектов на карте) и тд.
Также могут быть сформированы и другие специфичные паттерны, если это потребуется.
Паттерны для проверки критериев могут использоваться отдельно (атомарно), а могут быть объедены в следующие группы:
Цепочка. Обязательно выполнение всех перечисленных в цепочке критериев для положительного результата.
Набор. Достаточно выполнения одного любого критерия из набора для положительного результата.
Набор цепочек. Достаточно получения положительного результата для одной любой цепочки из набора для положительного результата.
Цепочка наборов. Обязательно получения положительного результата для всех наборов из цепочки для положительного результата.
Основные паттерны, описанные в модуле:
Float – касающийся чисел;
Dir – касающийся справочных значений;
Rel – касающийся связей;
Text – касающийся текста.
Структура XML#
Основные используемые теги:
CriteriaCheckSettings – обязательный тег с которого начинается xml.
Для него параметр visible – по умолчанию false. Данный параметр включает или отключает видимость кнопки для услуги, чтобы установить видимость true нужно добавить этот тег. CheckTypeAppl – по умолчанию false. Если у услуги есть связь с заявлением, то доступна возможность в XML указать вид заявления в параметре alias блока TypeAppl. Указанные виды заявлений будут использованы для того, чтобы определить - отображать на карточке услуги (объекта) кнопку плагина или нет. Для того, чтобы проверять вид заявления необходимо в CheckTypeAppl указать true.
2. TypeAppl – обязательный тег. Если CheckTypeAppl = true, то смотрим на вид заявления у услуги, что позволяет задавать разные критерии под разные виды заявлений для одной и той же услуги. resultAlias – карточка результата проверки. criterionAlias – карточка критерия. serviceToResultRelationAlias – связь услуги с результатом услуги rejectionResultAlias – карточка отрицательного результата услуги mismatchReasonTypeAlias – справочник причин несоответствия/отказа. rejectionToReasonLinkAlias – связь результата с причной несоответствия/отказа. resultToServiceRelationAlias – связь отрицательного результата услуги с услугой. Criterion – не обязательный тег, необходим для проверки какого-либо критерия.
Включить или отключить критерий, убрать или добавить в список проверяемых критериев, можно при помощи параметра visible. NeedToCheck – обращение к результату критерия по его id.
Кроме того, в зависимости от задачи могут встречаться оператор And, Or, CheckField, If или ChangeBaseModel. Эти теги являются не обязательными.
Частные случаи использования тегов:
SaveResById/LoadResById – хранение (подгрузка) объекта, найденного по цепочке, для дальнейшего взаимодействия с ним, если потребуется. SaveResById ставится в конце цепочки CheckField, LoadResById в начале цепочки CheckField и в операторе смены проверяемой модели ChangeBaseModel. После LoadResById можно идти дальше по цепочке либо проверить любое поле. Pезультаты сохраняются на время всей проверки целиком, причем необходимо обратить внимание, что в ситуации, когда два результата сохранены под одним идентификатором, будет использоваться только последний из них. Работает для всех type. В начале проверки всегда создается специальный объект startModel, соответствующий проверяемой услуге.
relAlias=ResultById=»номер». Применяется в ситуации, когда необходимо сравнить значение поля со значением сохраненного поля. По указанному номеру находится сохраненный результат с тегом SaveResById=»номер «. Работает только для type=»Float».
«NotStoredFloatField» – вычислимое поле, применяется в ситуации, когда необходимо взять два поля (необходимо сохранять поля через saveResById перед тем как использовать NotStoredFloatField) и преобразовать их в одно вычислимое, по формуле: значениеПоля1 / значениеПоля2 * 100. В этом случае в XML необходимо обязательно указать: alias = «NotStoredFloatField» type=»Float» operator = «любой» relAlias = «любой» и loadResById=»номер1; номер2» обязательно через “;” и обязательно в нужной последовательности (loadResById=»15;16» != loadResById=»16;15»).
Ошибки возможны в ситуациях, когда одно из сохраненных полей ничего не содержит (null), поэтому крайне важно проверять поля на null перед тем как использовать вычислимое поле. Цепочка обязательно должна содержать только один элемент оператор CheckField. Работает только для type=»Float».
Специфика работы с operator=»Or».
Встречаются ситуации, когда необходимо внутри тега Or добавить тег And.
Пример
<Operation operator="Or">
<Operation operator="And">
<Operation operator="CheckField" successMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}".">
<ChainField alias="TypeOKSHb" type="Dir" operator="Eq" relAlias="Home" loadResById="20"/>
</Operation>
<Operation operator="CheckField" successMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}". По предварительному анализу строительство объекта допустимо, проверьте корректность результата.">
<ChainField alias="UseKindByDoc" type="Text" operator="MatchRegex" relAlias="(?<!(\d|\.))2\.(1|2)(?!(\.\d|\d))" loadResById="21"/>
</Operation>
</Operation>
<Operation operator="And">
<Operation operator="CheckField" successMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}".">
<ChainField alias="TypeOKSHb" type="Dir" operator="Eq" relAlias="Garden" loadResById="20"/>
</Operation>
<Operation operator="CheckField" successMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}". По предварительному анализу строительство объекта допустимо, проверьте корректность результата.">
<ChainField alias="UseKindByDoc" type="Text" operator="MatchRegex" relAlias="(?<!(\d|\.))13\.2(?!(\.\d|\d))" loadResById="21"/>
</Operation>
</Operation>
<!-- отобразить отрицательный результат -->
<Operation operator="And">
<Operation operator="CheckField" successMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}".">
<ChainField alias="TypeOKSHb" type="Dir" operator="IsNotNull" loadResById="20"/>
</Operation>
<Operation operator="CheckField" errorMessage="В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}". Требуется дополнительный анализ пользователем.">
<ChainField alias="UseKindByDoc" type="Text" operator="MatchRegex" relAlias="StatisticallyImpossibleValue0098dce9-322d-44a9-b92b-9604afe9d755" loadResById="21"/>
</Operation>
</Operation>
</Operation>
Может возникнуть ситуация, когда не выполняются оба условия, и необходимо вывести сообщение errorMessage=»В карточке "{objectName}" значение поля "{fieldName}" равно "{fieldValue}". Требуется дополнительный анализ пользователем.». Например, если TypeOKSHb = Home, но UseKindByDoc не содержит relAlias, и необходимо перейти во второй and и TypeOKSHb != Garden. В таком случае выйдет сообщение об ошибке “Поле TypeOKSHb не равно Garden”. Для того, чтобы вышло верное сообщение, необходимо добавить третье условие, которое точно будет содержать отрицательный результат (то есть необходимо в relAlias добавить =*»StatisticallyImpossibleValue0098dce9-322d-44a9-b92b-9604afe9d755»*).
В случае type=»Text» operator=»MatchRegex» relAlias должен содержать регулярное выражение.
6. Операторы Intersects и NotIntersects, которые применяются для нахождения пересечения между объектами, позволяют указать размер буфера (в метрах), добавляемого к геометрии одного или нескольких проверяемых объектов в виде buffer=»40». Буфер для объекта рассчитывается в коде модуля при запуске проверки критериев по соответствующей кнопке. Для вычисления буфера и поиска пересечения используются утилиты Geometa - ISpatialTableObjectGateWay, ISpatialOperationsExecutor.
Операция с оператором If должна содержать ровно 3 вложенных операции: проверяемое условие; операцию проверки, которую необходимо произвести в случае положительного результата условия; операцию проверки, которую необходимо произвести в случае отрицательного результата. В противном случае при проведении проверки будет выдано сообщение об ошибке в описании xml.
ChangeBaseModel – оператор смены проверяемой модели (используется, например, в критериях по услугам Утверждение СРЗУ и Предварительное согласование предоставления ЗУ, для проверки нескольких СРЗУ и нескольких Границ образуемого ЗУ). Операция с ChangeBaseModel должна содержать ровно одну вложенную операцию. В противном случае при проведении проверки будет выдано сообщение об ошибке в описании xml. Работает только при указании атрибута loadPattern.
linkAlias - связь критерия с проверенным в нем объектом, в случае проверки множественных объектов.
Далее представлена общая структура xml с примером одного критерия и комментариями, содержащими описание различных параметров, тегов и блоков:
Пример
<?xml version="1.0"?>
<CriteriaCheckSettings visible="true" checkTypeAppl="false">
<!-- visible - вкл/откл видимость кнопки для услуги. checkTypeAppl - вкл/откл проверку на вид заявления -->
<TypeAppl resultAlias="ServiceCheckModuleResult" criterionAlias="ServiceCheckModuleComparableCriterion" mismatchReasonTypeAlias="DocRefMismatchReasonType" serviceToResultRelationAlias="WfRelServiceNotificationAboutBuilding" rejectionResultAlias="DocNotificationConstructionIsNotAllowed" rejectionToReasonLinkAlias="MismatchReason">
<Criterion visible="true" name="Проверка соответствия площади планируемого объекта строительства (садовый дом) установленной норме (100 кв.м.)" id="1">
<!-- Критерий с возможностью отключения по тегу visible-->
<!—NeedToCheck – обращение к результату критерия по его id-->
<Operation operator="And">
<!--операция And - логическая операция "и". Требуется соблюдение обоих условий
операция or - логическая операция "или". Требуется соблюдение хотя бы одного-->
<Operation operator="CheckField">
<!-- Если содержит ChainField, то необходимо пройти до поля из другой карточки-->
<ChainField alias="WfRelNotificationAndService" type="Rel"/>
<ChainField alias="DocRelHB" type="Rel"/>
<ChainField alias="TypeOKSHb" type="Dir" operator="Eq" relAlias="Garden"/>
<!-- type - используемый паттерн. Float - числовой, Dir - справочник, Rel - связь-->
<!-- дойти до поля TypeOKSHb, проверить равенство значению Garden
relAlias - это значение, с которым сравниваем Alias из справочника или само значение в других случаях-->
<!— Другие параметры для ChainField: FilterByLt - алиас логической таблицы для фильтрации MR связей.
Where – используется для проверки FieldValues.Alias на определенный результат
SaveResById (LoadResById) – хранение (подгрузка) объекта, найденного по цепочке, для дальнейшего взаимодействия с ним, если потребуется-->
- <!– variant - задает варианты, которые записываются в результат критерия. Можно указать на любом этапе, но если по цепочке указан дважды, то второй перезатрет первый, поэтому подразумевает указание в конце критерия–>
<!– id - идентификатор для тега variant, который запишется в результат критерия–> <!–Операции: GT - >, LT-<, GE->=, LE - <=, Eq - =
операция HasGeometry - проверить наличие геометрии операция CountLt - операция «Количество меньше» операция CountGt- операция «Количество больше» операция Variant – используется, для выбора варианта (по id) записываемого в результат критерия, из вариантов, заданных тегом variant для CheckField. Оператор Variant можно указывать несколько раз операция IsNotNull - операция проверки на Null–>
<!– MismatchReasonAlias - алиас причины несоответствия, подставляемой в случае отрицательного результата проверки–> <Operation operator=»Or»>
- <Operation operator=»CheckField» successMessage=»Проверка не производилась. Планируемый объект строительства не является садовым домом.»>
<!– Если содержит ChainField, то необходимо пройти до поля из другой карточки–> <ChainField alias=»WfRelNotificationAndService» type=»Rel»/> <ChainField alias=»DocRelHB» type=»Rel»/> <ChainField alias=»TypeOKSHb» type=»Dir» operator=»Neq» relAlias=»Garden»/>
</Operation> <Operation operator=»And»>
<Operation operator=»CheckField»> <ChainField alias=»WfRelNotificationAndService» type=»Rel»/> <ChainField alias=»DocRelHB» type=»Rel»/> <ChainField alias=»TypeOKSHb» type=»Dir» operator=»Eq» relAlias=»Garden»/>
</Operation> <Operation operator=»CheckField»>
<ChainField alias=»WfRelNotificationAndService» type=»Rel»/> <ChainField alias=»DocRelHB» type=»Rel»/> <ChainField alias=»AreaPr» type=»Float» operator=»IsNotNull»/>
</Operation> <Operation operator=»CheckField» mismatchReasonAlias=»DocRefMismatchReasonType_3» successMessage=»В карточке "{objectName}" значение поля "{fieldName}" меньше или равно {targetValue} кв. м. « errorMessage=»В карточке "{objectName}" значение поля "{fieldName}" больше {targetValue} кв. м.»>
- <!–проверка условия. Вывод сообщения при его выполнении или невыполнении. successMessage - сообщение о положительном результате. errorMessage - отрицательный результат –>
<ChainField alias=»WfRelNotificationAndService» type=»Rel»/> <ChainField alias=»DocRelHB» type=»Rel»/> <ChainField alias=»AreaPr» type=»Float» operator=»Le» relAlias=»100»/>
</Operation>
</Operation>
</Operation>
</Criterion> … </TypeAppl> </CriteriaCheckSettings>
Формирование сообщений#
Сообщение с результатом проверки по критерию выводится в поле [Детали проверки] в созданной после проверки критерия карточке. Сообщение формируется либо из дефолтных шаблонов, описанных для различных паттернов и зашитых в модуль на бэкенде, либо из кастомных сообщений, которые описываются непосредственно в xml в критериях, где будут использованы.
Дефолтные шаблоны формирования сообщений описываются в модуле на бэкенде в методе getErrorMessage для каждого паттерна. Далее приведены текстовки дефолтных сообщений из паттернов Dir, Rel, Float, причем как в дефолтных, так и в кастомных шаблонах:
{objectName} – полное наименование объекта (full_name); {fieldName} – наименование поля из карточки объекта; {relationName} – наименование связи между объектами; {targetValue} – заданное значение; {fieldValue} - значение указанного поля, причем: если тип поля – Rel (ссылка на объект), то это полное наименование объекта (full_name), если тип поля – Dir (ссылка на элемент справочника), то это наименование справочного значения, соответствующее alias элемента справочника.
Паттерн Dir:
«В карточке "{objectName}" значение поля "{fieldName}" не соответствует значению "{targetValue}".»; «В карточке "{objectName}" значение поля "{fieldName}" соответствует значению "{targetValue}".»; «В объекте "{objectName}" в поле "{fieldName}" отсутствуют сведения.».
Паттерн Rel:
«У объекта {objectName} не задана геометрия.»; «Найдено пересечение с объектами "{relationName}". Количество пересечений больше или равно {targetValue}.»; «В карточке "{objectName}" количество связанных "{relationName}" больше или равно {targetValue}.»; «Пересечений с объектом "{relationName}" не обнаружено.» «Найдено пересечение с объектами "{relationName}". Количество пересечений меньше или равно {targetValue}.»; «В карточке "{objectName}" в поле "{relationName}" отсутствуют сведения.» «В карточке "{objectName}" количество связанных "{relationName}" меньше или равно {targetValue}.»; «Объекты в поле "{relationName}" с буфером {field.Buffer} м. не пересекаются с объектами "{targetValue}".» «Объекты в поле "{relationName}" с буфером {field.Buffer} м. пересекаются с объектами "{targetValue}".» «Не соответствует.».
Паттерн Float:
«В объекте "{objectName}" в поле "{fieldName}" отсутствуют сведения.»; «В объекте "{objectName}" в поле "{fieldName}" отсутствует "{targetValue}".».
Пример описания пользовательского сообщения в одном из проверяемых критериев:
<Operation operator="CheckField"
mismatchReasonAlias="DocRefMismatchReasonType_3"
successMessage="В карточке "{objectName}" значение поля "{fieldName}" меньше или равно {targetValue} кв. м."
errorMessage="В карточке "{objectName}" значение поля "{fieldName}" больше {targetValue} кв. м.">
<!--проверка второго условия. Вывод сообщения при его выполнении или невыполнении. successMessage - сообщение о положительном результате. errorMessage - отрицательный результат -->
…
</Operation>
Описание работы#
Модуль проверки на наличие оснований в отказе имеет архитектуру, представленную на рисунке:

По запросу от плагина, модуль обращается к настройкам и вычитывает aliasы объектов (услуг), на карточках которых должен отображаться плагин.
Также модуль на бэкенде обращается к базе данных (далее - БД) PostgreSQL через сервисы основного приложения и вычитывает права пользователя на создание, редактирование карточки объекта, карточки отказа.
Таким образом определяется отображать пользователю кнопки на плагине или нет.
В БД осуществляется запись, чтение, хранение атрибутов, которые используются для различных проверок. Кроме того, в БД находятся различные справочники, в том числе справочник с причинами отказа по той или иной услуге, виду заявления.
Подключение пользователей#
Кнопка «Проверка на несоответствия» с выпадающим списком действий отображается только для пользователей, у которых есть доступ на редактирование этих карточек услуг, для которых предназначен модуль.
Кнопка не отображается до первого сохранения объекта. Т.е. во вновь созданной карточке услуги кнопка отобразится только после первого сохранения этой карточки с услугой. Для уже существующих объектов кнопка отображается по вышеописанному правилу.
Если в карточке конкретной услуги значение в поле [Проверки (CheckModuleResult)] отсутствует (ни одной проверки не было произведено в рамках этой услуги), то действие «Создать отрицательный результат услуги» на кнопке «Проверка на несоответствия» не доступно. Также действие не отображается для тех пользователей, у которых нет доступа на редактирование карточки с отрицательным результатом по услуге.