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

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

Сводка

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

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

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

1. В базовом макете приложения создайте триггеры уровня On Step ExitStep, как показано ниже:
2. В приложении создайте шаг с именем Submit Correction Context, который включает:
3. Input Widget(ы) для захвата контекста, например кода причины исправления, с помощью ввода с одним выбором и/или комментариев к исправлению с помощью текстового ввода.
4. Кнопка " Предыдущий" или " Отмена", позволяющая оператору выйти из этого шага.

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

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

При просмотре партии в виджете {{глоссарий.История цифровых записей}} Виджет, сортировка от старого к новому и фильтрация по имени шага приложения покажет следующее: * Зарегистрированные данные процесса для шага процесса со значением для Is Correction равным "No", с различными переменными и значениями

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

:::(Info) (ПРИМЕЧАНИЕ) Не нужно фильтровать виджет истории записей по шагу с исправлением. Без этого фильтра рецензент увидит всю историю партии: