Задача входного контроля: Что такое Входной контроль: виды, описание

Содержание

Входной контроль проектно-сметной документации

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

Определение понятия входного контроля

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

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

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

Цели и задачи входного контроля сметной документации

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

Основные задачи входного контроля сметной документации состоят в следующем:

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

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

Кто осуществляет контроль документации

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

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

На что обращают внимание при проверке

Контроль качества проектной документации подразумевает всестороннее и тщательное изучение всех, касающихся строительства документов. При осуществлении контроля проверяются:

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

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

Основные правила и сроки

Контроль строительной проектно-сметной документации (ПСД) – комплекс работ, состоящий из ряда процедур и исследовательских мероприятий. Правилами предусмотрены следующие типы контроля:

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

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

Результат проверки

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

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

В выводах указываются рекомендации по усовершенствованию принятых решений и устранению ошибок с финансовой и технической оценкой изменений.

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

Заключение

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

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

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

Обеспечение входного контроля, учета и документооборота

Входной контроль

Наша компания оказывает услуги входного контроля при приеме продукции на склады ответственного хранения.

Основная задача входного контроля — проверка качества, комплектности, маркировки, упаковки, характеристик и свойств поставляемой продукции на соответствие транспортным документам, заказу и НТД на их производство, сертификатам качества заводов-изготовителей, а также определение причин возникновения несоответствий, если это при возможно.

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

Основные мероприятия входного контроля АО «Беломортранс»:

Приемка МТР по качеству, количеству и комплектности;
Участие в комиссиях по приемке МТР совместно со службами заказчика;
Составление актов несоответствия;
В случае необходимости, отбор проб и оформление результатов приемки и отбора проб.

Обеспечение входного контроля осуществляется профессиональными сотрудниками — инспекторами входного контроля. Они обладают соответствующими удостоверениями специалистов ВКиК (входной контроль и комплектация), прошли обучение и аттестацию ОТТБ и ПБ, имеют опыт работы не менее 2-х лет.

Все специалисты ВКиК АО «Беломортранс» обеспечены необходимыми техническими средствами, средствами контроля и измерительными приборами для организации работ.

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

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

Учет и документооборот

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

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

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

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

Подробную информацию о данной услуге вы можете получить у наших специалистов по телефону +7 (495) 514-02-55 или направить запрос по адресу [email protected].

Связаться с нашим специалистом

Задачи сборки и выпуска — Azure Pipelines

Редактировать

Твиттер

Фейсбук

Эл. адрес

Статья
21. 12.2022
12 минут на чтение

Службы Azure DevOps | Azure DevOps Server 2022 — Azure DevOps Server 2019 | TFS 2018

Примечание

В Microsoft Team Foundation Server (TFS) 2018 и предыдущих версиях
сборка и выпуск конвейеров называются определениями ,
прогонов называются билды ,
служебных подключений называются конечными точками службы ,
этапы называются средами ,
и заданий называются этапами .

Задача — это стандартный блок для определения автоматизации в
трубопровод.
Задача — это просто упакованный сценарий или процедура,
абстрагируется набором входных данных.

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

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

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

Узнайте больше о том, как указать свойства задачи с помощью встроенных задач.

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

Пользовательские задачи

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

Кроме того, Visual Studio Marketplace
предлагает множество расширений; каждый из которых при установке на ваш
подписка или коллекция, расширяет каталог задач одной или несколькими задачами.
Кроме того, вы можете написать свои собственные расширения
для добавления задач в Azure Pipelines или TFS.

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

 шагов:
- задача: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #пример формата
- задача: qetza.replacetokens.replacetokens-task.replacetokens@3 #рабочий пример

Чтобы найти myPublisherId и myExtensionId , выберите Получить в задании на торговой площадке. Значения после itemName в вашей строке URL-адреса: myPublisherId и myExtensionId . Вы также можете найти полное имя, добавив задачу в конвейер выпуска и выбрав Просмотр YAML при редактировании задачи.

Версии задач

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

При выпуске новой дополнительной версии (например, от 1.2 до 1.3) ваша сборка или выпуск
будет автоматически использовать новую версию. Однако, если будет выпущена новая основная версия
(например, 2.0), ваша сборка или выпуск будут по-прежнему использовать указанную вами основную версию.
пока вы не отредактируете конвейер и не перейдете вручную на новую основную версию.
Журнал сборки или выпуска будет содержать предупреждение о наличии новой основной версии.

Вы можете указать, какая дополнительная версия будет использоваться, указав полный номер версии задачи после знака @ (пример: GoTool@0. 3.1 ). Вы можете использовать только те версии задач, которые существуют для вашей организации.

YAML
Классический

В YAML вы указываете основную версию, используя @ в имени задачи.
Например, чтобы закрепить на версии 2 задачи PublishTestResults :

 шагов:
- задача: PublishTestResults@2

Конвейеры

YAML недоступны в TFS.

Опции управления задачами

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

YAML
Классический

Опции управления доступны в виде клавиш в разделе задача .

 - задача: строка # ссылка на задачу и версию, например. "VSBuild@1"
  условие: выражение # см. ниже
  continueOnError: boolean # 'true', если будущие шаги должны выполняться, даже если этот шаг завершится ошибкой; по умолчанию «ложь»
  enabled: boolean # запускать этот шаг или нет; по умолчанию «истина»
  timeoutInMinutes: number # сколько ждать перед истечением времени выполнения задачи

Опции управления доступны в виде клавиш в разделе задачи .

 - задача: строка # ссылка на задачу и версию, например. "VSBuild@1"
  условие: выражение # см. ниже
  continueOnError: boolean # 'true', если будущие шаги должны выполняться, даже если этот шаг завершится ошибкой; по умолчанию «ложь»
  enabled: boolean # запускать этот шаг или нет; по умолчанию «истина»
  timeoutInMinutes: number # сколько ждать перед истечением времени выполнения задачи
  target: string # 'host' или имя ресурса-контейнера для таргетинга

Опции управления доступны в виде клавиш в разделе задачи .

 - задача: строка # ссылка на задачу и версию, например. "VSBuild@1"
  условие: выражение # см. ниже
  continueOnError: boolean # 'true', если будущие шаги должны выполняться, даже если этот шаг завершится ошибкой; по умолчанию «ложь»
  enabled: boolean # запускать этот шаг или нет; по умолчанию «истина»
  retryCountOnTaskFailure: number # Максимальное количество попыток; по умолчанию ноль
  timeoutInMinutes: number # сколько ждать перед истечением времени выполнения задачи
  target: string # 'host' или имя ресурса-контейнера для таргетинга

Примечание

Данная задача или задание не может в одностороннем порядке решать, продолжать ли задание/стадию. Что он может сделать, так это предложить статус успешно выполнено или не выполнено , и у каждой нижестоящей задачи/задания есть вычисление условия, которое позволяет им решать, запускать их или нет. Условие по умолчанию, которое эффективно «запускается, если мы находимся в успешном состоянии».

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

Период ожидания начинается с момента запуска задачи. Он не включает
время, когда задача поставлена в очередь или ожидает агента.

В этом YAML PublishTestResults@2 будет выполняться, даже если предыдущий шаг завершится ошибкой из-за условия successedOrFailed().

 шагов:
- задача: UsePythonVersion@0
  входы:
    версияSpec: '3. x'
    архитектура: "x64"
- задача: PublishTestResults@2
  входы:
    testResultsFiles: "**/TEST-*.xml"
  условие: удалось или не удалось ()

Условия

Только если все предыдущие прямые и косвенные зависимости с одним и тем же пулом агентов были успешными. Если у вас разные пулы агентов, эти этапы или задания будут выполняться одновременно. Это значение по умолчанию, если в YAML не задано условие.
Даже если предыдущая зависимость не удалась, если запуск не был отменен. Используйте successedOrFailed() в YAML для этого условия.
Даже если предыдущая зависимость не удалась, даже если выполнение было отменено. Используйте always() в YAML для этого условия.
Только в случае сбоя предыдущей зависимости. Используйте failed() в YAML для этого условия.

Пользовательские условия, состоящие из выражений

Цель шага

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

 ресурсов:
  контейнеры:
  - контейнер: pycontainer
    изображение: питон: 3.11
шаги:
- задача: SampleTask@1
  цель: хозяин
- задача: AnotherTask@1
  цель: pycontainer

Здесь SampleTask запускается на хосте, а AnotherTask запускается в контейнере.

Количество повторных попыток в случае сбоя задачи

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

 - задача: <имя задачи>
   retryCountOnTaskFailure: <максимальное количество попыток>
   ...

Примечание

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

Конвейеры

YAML недоступны в TFS.

Переменные среды

YAML
Классический

Конвейеры YAML поддерживаются в Azure DevOps Server 2019 и более поздних версиях.

Каждая задача имеет свойство env , которое представляет собой список пар строк, представляющих переменные среды, сопоставленные с процессом задачи.

 задача: AzureCLI@2
отображаемое имя: Azure CLI
inputs: # Индивидуально для каждой задачи
среда:
  ENV_VARIABLE_NAME: значение
  ENV_VARIABLE_NAME2: значение
  . ..

В следующем примере выполняется шаг сценария , который является ярлыком для задачи командной строки, за которым следует эквивалентный синтаксис задачи. В этом примере присваивается значение переменной среды AZURE_DEVOPS_EXT_PAT , которая используется для проверки подлинности с помощью интерфейса командной строки Azure DevOps.

 # Использование синтаксиса ярлыка скрипта
- скрипт: список групп переменных конвейеров az --output table
  среда:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'Вывести список групп переменных, используя шаг скрипта'
# Использование синтаксиса задачи
- задача: CmdLine@2
  входы:
    сценарий: список групп переменных конвейеров az --output table
  среда:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'Вывести список групп переменных с помощью задачи командной строки'

`Установщики инструментов сборки (Azure Pipelines)`

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

Установить инструмент или среду выполнения «на лету» (даже на агентах, размещенных в Microsoft) как раз к сборке CI.
Проверьте свое приложение или библиотеку на соответствие нескольким версиям зависимости, например Node.js.

Например, вы можете настроить конвейер сборки для запуска и проверки вашего приложения для нескольких версий Node.js.

`Пример. Протестируйте и проверьте свое приложение на нескольких версиях Node.js`

YAML
Классический

Создайте файл azure-pipelines.yml в базовом каталоге проекта со следующим содержимым.

 бассейн:
  vmImage: ubuntu-последняя
шаги:
# Установка узла
- задача: NodeTool@0
  displayName: установка узла
  входы:
    versionSpec: '12.x' # Версия, которую мы устанавливаем
# Записываем установленную версию в командную строку
- скрипт: какой узел

Создайте новый конвейер сборки и запустите его. Обратите внимание на то, как выполняется сборка. Установщик Node.js Tool загружает версию Node.js, если ее еще нет в агенте. Сценарий командной строки регистрирует расположение версии Node.js на диске.

Конвейеры

YAML недоступны в TFS.

`Задачи установщика инструментов`

Список наших задач установщика инструментов см. в разделе Задачи установщика инструментов.

`Отключение встроенных задач и задач Marketplace`

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

Работа
Целевые группы
Встроенный каталог задач

`Справка и поддержка`

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

`Обратная связь`

Отправить и просмотреть отзыв для

Этот продукт

Эта страница

Просмотреть все отзывы о странице

`Создание задачи ввода — процессы`

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

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

Первый экран, через который сотрудник может ввести данные о расходах.
Еще один экран, который откроется после того, как менеджер получит уведомление о задаче.

Эта форма будет открыта, когда менеджер получит уведомление о задаче ввода. Он будет содержать все детали из предыдущей формы. Также будет добавлен дополнительный элемент управления для Утвержденной суммы, которая будет суммой расходов, возмещаемых после утверждения менеджером.

Существует два способа привязки данных к этой форме. Одним из них является использование параметров строки запроса.

В этом примере мы добавим переменную строки запроса, которая будет использоваться в задаче ввода. Чтобы определить параметры строки запроса, перейдите в «Настройки» > «Строка запроса» и нажмите «Добавить строку запроса» (+). Теперь вы можете добавить имя переменной для использования, а затем назначить фиктивные значения, которые можно увидеть в качестве предварительного просмотра. Это связано с тем, что параметры строки запроса будут вызываться из задачи ввода для получения значений. Теперь давайте создадим рабочий процесс для задачи ввода.

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

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

Теперь, чтобы добавить задачу ввода в рабочий процесс, выберите параметр Задача ввода в разделе «Выбор задачи».

Теперь добавьте к этой задаче ИМЯ ЗАДАЧИ. Рекомендуется использовать осмысленное имя для задачи, так как этот текст виден пользователю в приложении состояния всякий раз, когда задача выполняется.

Вы можете поместить условие/критерий в КОГДА ВЫПОЛНЯТЬ , которые будут оцениваться механизмом рабочего процесса, чтобы определить, следует ли выполнять текущие задачи или нет. Условие/критерий необходимо оценить как ИСТИНА (логическое значение ИСТИНА) для выполнения задачи. Если оставить критерии пустыми, задача будет выполняться всегда.

Вы можете использовать динамические данные при выполнении рабочих процессов. Например, если вы хотите отобразить адрес электронной почты пользователя, который инициировал/запустил рабочий процесс, вы можете сделать это, используя ключевое слово рабочего процесса INITIATED.INPUTBYEMAIL, которое должно быть помещено в двойные фигурные скобки {{}}, как показано на изображение выше. Это отобразит адрес электронной почты пользователя в приложении Status, когда рабочий процесс будет выполнен.

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

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

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

После этого вам необходимо настроить параметр Назначить задачу конкретному пользователю или группе пользователей.

После выбора нужного экрана для открытия необходимо назначить пользователей для текущей задачи в разделе НАЗНАЧИТЬ ЗАДАЧУ. Вы можете назначать задачи непосредственно отдельному пользователю или группе пользователей на основе иерархии пользователей.

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

Если вы хотите назначить какое-либо ограничение по времени для задачи, вы можете сделать это, указав количество часов в поле DEADLINE в разделе Configuration. Вы также можете включить параметр «Переназначить задачу», если хотите переназначить текущую задачу другому пользователю.

После выполнения всех настроек нажмите кнопку «Готово», чтобы сохранить настройки задачи. Вновь созданные задачи будут отображаться, как показано на изображении ниже. Вы можете добавить новую задачу до или после текущей, нажав на соответствующий знак «+». В этом примере мы добавляем задачу «Обновить лист» для вставки записей в лист для утвержденной суммы расходов.

Точно так же вы можете создать столько задач INPUT FORM в рабочем процессе, сколько вам нужно.

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

Затем задача ввода извлекает ввод из предыдущей формы и обрабатывает его в зависимости от указанных действий.

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

Теперь посмотрим на вывод:

Форма отправки возмещения:

Назначение задачи конкретному пользователю (инициатору в данном примере)

Задача ввода, запущенная при нажатии Открыть задачу

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