MENU
    Исправления в данных о процессах и их обзор
    • 08 Jan 2025
    • 2 Минуты для чтения
    • Авторы

    Исправления в данных о процессах и их обзор


    Вводный текст

    В этой статье рассматривается передовая практика регистрации исправлений в партиях.

    Сводка

    • Используйте общий шаг Submit Correction для регистрации кода причины и/или комментариев.
    • Используйте триггер выхода на шаге, чтобы сохранить текущий шаг процесса в переменной предыдущего шага или в таблице Field, где Is Correction в данный момент имеет значение False.
    • Используйте булевую переменную Is Correction и установите значение по умолчанию на Yes при переходе к шагу Submit Correction. Это поможет улучшить видимость в приложениях для рецензирования eBR.
    • После отправки информации об отправке исправления переместите пользователя на предыдущий шаг (как сохранено в переменной или поле таблицы).
    • На предыдущем шаге оператор введет новую информацию и перейдет к следующему шагу.

    Решение для прохода

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

    1. В базовом макете приложения создайте триггеры уровня On Step ExitStepследующего вида:Robustness to App Cancellations - App Base Layout - On Step Exit Trigger v2.png{height="" width=""}.
    2. В приложении создайте шаг с именем Submit Correction Context, который включает:
    3. Input Widget(ы) для захвата контекста, например кода причины исправления, с помощью единственного выбора и/или комментариев к исправлению с помощью текстового ввода.
    4. Кнопка "Предыдущий" или "Отмена", позволяющая оператору выйти из этого шага.

    Robustness to App Cancellations - App - Submit Correction Context Step 2.png

    1. Создайте кнопку "Отправить" и настройте для нее следующую логику срабатывания:
    2. Действие: Data Manipulation -> Store -> Static Value -> "yes" -> Boolean variable called Is Correction
    3. Действие: App -> Save All App Data
    4. Переход: Переход к шагу по имени -> Запись таблицы / партия / предыдущий шаг процесса

    Robustness to App Cancellations - App - Submit Correction Context - Submit Button Trigger.png

    1. На предыдущем шаге из контекстного шага Submit Correction Context создайте кнопку Next, которая имеет следующую логику срабатывания:
    2. Действие: Манипулирование данными -> Очистить -> (каждая переменная, используемая в этом шаге)
    3. ПРИМЕЧАНИЕ: Переменные, присутствующие на этом шаге, не нужны для расчета на последующем шаге. Этот метод позволит очистить виджет истории записей, просматриваемый в таких приложениях, как eBR Review или eDHR Review.
    4. Действия: Манипулирование данными -> Сохранить -> Статическое значение -> Булево -> Нет -> Исправлено
    5. Действия: Манипулирование данными -> Очистить -> (каждая переменная, используемая в шаге Submit Correction Context )
    6. Действия: App -> Save All App Data
    7. Переход: Перейти к шагу -> Следующий

    Robustness to App Cancellations - App - Process Steps - Next button Trigger logic.png

    При просмотре партии в виджете Digital Record History Виджет, сортировка от старого к новому и фильтрация по имени шага приложения покажет следующее:* Зарегистрированные данные процесса для шага процесса со значением "Нет" для параметра " Коррекция ", с различными переменными и значениямиimage.png

    • Зарегистрированные данные процесса для того же этапа процесса, но со значением для Is Correction равным "Yes" и новыми значениями переменных.
    • Любой контекст из шага Submit Correction Context (например, код причины исправления)image.png
    NOTE

    You do not need to filter the Record History Widget by the step with the correction. Without that filter, the reviewer will see the full history of the Batch.


    Была ли эта статья полезной?